Bug 1204674 - %defattr(755,root,root) no longer applies to directories
Summary: %defattr(755,root,root) no longer applies to directories
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rpm
Version: 7.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Florian Festi
QA Contact: Karel Srot
: 1205074 (view as bug list)
Depends On: 997774
TreeView+ depends on / blocked
Reported: 2015-03-23 10:51 UTC by Patrik Kis
Modified: 2015-11-19 11:58 UTC (History)
1 user (show)

Fixed In Version: rpm-4.11.3-10.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 997774
Last Closed: 2015-11-19 11:58:38 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2138 0 normal SHIPPED_LIVE rpm bug fix and enhancement update 2015-11-19 10:39:52 UTC

Description Patrik Kis 2015-03-23 10:51:42 UTC
This bug also exists on RHEL-7.1:

+++ 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):

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



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

%dir /XXX

Steps to Reproduce:
1. rpmbuild -bb mini.spec
2. rpm -qplv mini-0.1-1.el6.noarch.rpm
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.

Comment 2 Florian Festi 2015-04-08 12:29:56 UTC
*** Bug 1205074 has been marked as a duplicate of this bug. ***

Comment 5 errata-xmlrpc 2015-11-19 11:58:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.