This bug also exists on RHEL-7.1:
rpm-4.11.1-25.el7

+++ This bug was initially created as a clone of Bug #997774 +++

Description of problem:
It appears that when bug 730473 was fixed (just after version 4.8.0-21?), a certain established behavior with the %defattr directive affecting %dir entries (with no %attr override) was broken.  The directive is documented with the following parameters:

    %defattr(<file mode>, <user>, <group>, <dir mode>)

where <dir mode> is optional.  The issue is when <dir mode> is omitted, how does rpmbuild handle a subsequent %dir entry (when no %attr is specified)?  It had previously (at least in el5 and el6 up through 4.8.0-21) applied the <file mode> to directories, as in the following example:

    %defattr(0770, root, root)
    %dir /XXX

The permissions of the /XXX directory in this case used to be set to 770.  After the bug 730473 fix, the above %defattr wouldn't apply to /XXX at all.  Instead, the permissions of this directory in the build install tree would be used (which might fluctuate, depending on the build process umask, etc.)


Version-Release number of selected component (if applicable):
rpm-4.8.0-32

How reproducible:
Build an rpm with this minimal spec file

--%<---------------------------------
Summary: foo
Name: mini
Version: 0.1
Release: 1%{?dist}
Group: System Environment/Daemons
License: GPLv2+
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-root

%description

%prep

%install
%{__install} -d %{buildroot}/XXX

%files
%defattr(0770,root,root)
%dir /XXX
--%<---------------------------------


Steps to Reproduce:
1. rpmbuild -bb mini.spec
2. rpm -qplv mini-0.1-1.el6.noarch.rpm
3.
  
Actual results:
drwxr-xr-x    2 root    root                        0 Aug 16 02:04 /XXX

Expected results:
drwxrwx---    2 root    root                        0 Aug 16 02:05 /XXX


Additional info:
If you repeat the above test on an el5 system or el6 system with an rpm version up to around 8.4.0-21, you will see the expected results.