RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 997774 - %defattr(755,root,root) no longer applies to directories
Summary: %defattr(755,root,root) no longer applies to directories
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Marek Marusic
URL:
Whiteboard:
Depends On:
Blocks: 1159820 1204674 1205074
TreeView+ depends on / blocked
 
Reported: 2013-08-16 08:06 UTC by Glenn Zazulia
Modified: 2015-07-22 07:02 UTC (History)
8 users (show)

Fixed In Version: rpm-4.8.0-40.el6
Doc Type: Bug Fix
Doc Text:
The behavior of the file mode and directory mode parameters for the %defattr directive was changed in a prior update, which caused building packages that still expected the previous behavior to fail or to experience problems. The directive has been reverted to the previous behavior, and a warning about the potential problems with %defattr has been added to the "rpmbuild" command.
Clone Of:
: 1204674 1205074 1581734 (view as bug list)
Environment:
Last Closed: 2015-07-22 07:02:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1452 0 normal SHIPPED_LIVE rpm bug fix and enhancement update 2015-07-20 18:43:47 UTC

Description Glenn Zazulia 2013-08-16 08:06:18 UTC 
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.
Comment 2 Panu Matilainen 2013-08-20 07:15:29 UTC 
Right. Technically restoring the former behavior would be trivial, I guess the big question here is: does the former behavior actually make sense? The exact semantics of %defattr are not documented anywhere AFAICT so its a matter of reader interpretation and implementation details (in this context, bugs :) that vary somewhat between versions.

The current implementation makes the rules very simple: if you want a default mode for directories, then you need to set one. A default mode for files rarely makes sense for directories due to the different semantics for eg executable bits, so having directory defattr fall back to file defattr setting is likely not what you really wanted. The obvious downside is that a long-standing behavior silently changed for the case reported here.
Comment 3 Glenn Zazulia 2013-08-20 17:48:04 UTC 
Yes, I agree that the former defattr behavior was never documented and that the current behavior is arguably simple, but I'm concerned about how this change silently and subtly breaks long-standing behavior, as you also noted.  My company builds rpms, and I found a number of spec files that are now broken since this last rpm fix.  I fixed a few of the spec files, since whether or not the long-standing behavior is restored, it seems more proper anyway to explicitly set that 4th dir_mode parameter.

I don't feel strongly about the necessity of restoring the old behavior for backward-compatibility, but I wanted to at least alert people to this incompatible change and perhaps open this to discussion.
Comment 4 Panu Matilainen 2013-08-21 12:17:54 UTC 
Sure, no disagreement there - silent behavior changes are nasty, even more so within a long-life distro version. One possibility is restoring the former behavior for RHEL-6, perhaps with a warning about ambiguous %defattr() when the file mode is applied to directories.
Comment 5 RHEL Program Management 2013-10-14 02:42:47 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 11 errata-xmlrpc 2015-07-22 07:02:54 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.

https://rhn.redhat.com/errata/RHBA-2015-1452.html
Note You need to log in before you can comment on or make changes to this bug.