Bug 997774 - %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 6
Classification: Red Hat
Component: rpm
Version: 6.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: Marek Marusic
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)
Last Closed: 2015-07-22 07:02:54 UTC
Target Upstream Version:

Attachments (Terms of Use)

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

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 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.


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