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