Bug 730473
Summary: | %defattr overrides %attr if directory default permission given | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Simon Matter <simon.matter> | ||||||
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 6.1 | CC: | charlieb-fedora-bugzilla, ffesti, iperegudov, john.horne, jpazdziora, ksrot, pkis, redhat, schlegel, zbitter | ||||||
Target Milestone: | rc | Keywords: | Regression | ||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2013-02-21 10:51:00 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 840699 | ||||||||
Attachments: |
|
Description
Simon Matter
2011-08-13 11:08:28 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Can confirm that problem still exists at RHEL 6.2. Rebuild security package 'aide' and it sets directory permissions as 755, should be 700 for security. SPEC file shows: ================================================ %files %defattr(0644,root,root,0755) %doc AUTHORS COPYING ChangeLog NEWS README doc/manual.html contrib/ %attr(0700,root,root) /usr/local/bin/aide /usr/local/share/man/man1/* /usr/local/share/man/man5/* %config(noreplace) %attr(0600,root,root) %{_sysconfdir}/aide.conf %config(noreplace) %{_sysconfdir}/logrotate.d/aide %dir %attr(0700,root,root) %{_localstatedir}/lib/aide %dir %attr(0700,root,root) %{_localstatedir}/log/aide ================================================ Both the /var/lib/aide and /var/log/aide directories have permissions 755 when installed rather than 700 as specified here. By putting '%defattr(0644,root,root,0700)' before the last two '%dir' lines then the permissions are correct. Just noticed that this is also reported as Fedora bug #681540. It seems that this has been fixed upstream, and can confirm it works okay on Fedora 15. Doh, this has gone completely forgotten until the recent activity (thanks for pinging). It's indeed a bug in rpm 4.8.x and certainly deserves to be fixed in RHEL. Unfortunately its too late for 6.3 at this point, but flagging it for 6.4 to ensure it gets processed then. *** Bug 803623 has been marked as a duplicate of this bug. *** *** Bug 804910 has been marked as a duplicate of this bug. *** *** Bug 805271 has been marked as a duplicate of this bug. *** (In reply to comment #5) > Doh, this has gone completely forgotten until the recent activity (thanks for > pinging). It's indeed a bug in rpm 4.8.x and certainly deserves to be fixed in > RHEL. Unfortunately its too late for 6.3 at this point, but flagging it for 6.4 > to ensure it gets processed then. Can you please identify where this bug was "fixed upstream" so that we can make an rpm of rpmbuild which works? I guess I could rebuild the version from F15, but that could open a can of worms. (In reply to comment #9) > Can you please identify where this bug was "fixed upstream" so that we can make > an rpm of rpmbuild which works? It was fixed in RPM 4.9.1, if that helps. I haven't gone looking for the exact commit. Created attachment 571844 [details]
Difference between 4.9.0 and 4.9.1
(In reply to comment #10) > It was fixed in RPM 4.9.1, if that helps. I haven't gone looking for the exact > commit. Thanks. I've attached the 4.9.0 -> 4.9.1 changeset. Created attachment 571850 [details] Patch to build/files.c It looks like changes to build/files.c are what is relevant. I applied that section of the patch to rpm-4.8.0-19.el6.src.rpm, and hand merged what patch couldn't handle. I'm now building that to try. I notice that part of the derived patch reverses this commit: http://www.rpm.org/gitweb?p=rpm.git;a=commitdiff;h=64e7f2aeb4ce01fccacde021fb22c85083284efb which is included in rpm-4.8.0-19.el6.src.rpm as rpm-4.8.0-fileattrs.patch. I notice also that 64e7f2aeb4ce01fccacde021fb22c85083284efb is the last commit to build/files.c in http://www.rpm.org/gitweb?p=rpm.git;a=history;f=build/files.c;h=2309ab6edce933ba2e2c39321ab11d3705d44f52;hb=64e7f2aeb4ce01fccacde021fb22c85083284efb So rpm-4.8.0-19 should be up-to-date wrt to upstream (IIUC). Is that last commit a bad patch, and should just be omitted? Here's the changelog from when that patch was added: ... * Thu Aug 11 2011 Florian Festi <ffesti> - 4.8.0-17 - Allow self conflicts (#651951) - Add support for xz compression in rpm2cpio.sh (#674348) - Don't error out on already imported GPG keys (#680889) - Fix file conflict handling for uncolored files (#705115) - Fix file attribute handling with %defattr(-) (#705993) - Don't error out when trying to add the same signature again (#707449) - Fix signature checking (#721363) ... I guess that "directory attribute handling with %defattr" wasn't verified at that time. A quick test suggests that the patch resolves this issue. bash-4.1$ rpm -q rpm rpm-build rpm-4.8.0-19.el6.cb.test.i686 rpm-build-4.8.0-19.el6.cb.test.i686 bash-4.1$ bash-4.1$ rpm -qlvp /home/speech/bradyc/rpms/RPMS/noarch/mini-0.1-1.el6.noarch.rpm drwx-wx--- 2 root nobody 0 Mar 21 17:15 /XXX/ bash-4.1$ (In reply to comment #0) > Novell has a BZ entry about this bug: > https://bugzilla.novell.com/show_bug.cgi?id=629048 That leads us to: https://bugs.launchpad.net/rpm/+bug/633729 where status was changed to "status: Confirmed → Fix Released" because somebody said "I think this was fixed some time ago". Nice! The patch that caused the regression is here: http://www.rpm.org/gitweb?p=rpm.git;a=commit;h=f6982a403b284012abc846d9f4e5155ad84fac35 The fix is: http://www.rpm.org/gitweb?p=rpm.git;a=commit;h=bcd673bcdea7bf9ab80621d3d767866e7a232e8d (in 4.9.1 - as noted in the commit log, that is a backport) 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. (In reply to comment #17) > This request was not resolved in time for the current release. And we have to ask "why not"? See comment #5 - this was supposedly flagged so that it *would* be fixed for 6.4. Then we did the work to find a patch for you. > 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. Please don't ask us to jump through hoops. This is a regression. Just fix it please. Sorry, I dont know what exactly went wrong here but this appears to have fallen through some kind of cracks in the ack'ing process. Marking this as a regression which it is now, hopefully that will allow getting it fixed in 6.4 despite this mixup. This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4. (In reply to comment #21) > This request > will be evaluated for inclusion in Red Hat Enterprise Linux 6.4. How's that going then? Panu fixed this upstream in July 2011. Hi, it should be fixed in 6.4. Thanks. Left aside that 6.4 is propably released in the not-so-distant future, I would expect a fix for this to be released on a fasttrack channel. (I am a paying RHEL customer running hundreds of RHEL systems and have just spend 3 hours on this issue. That is 3 hours too much as I only came across the issue month after it would have been possible for Red Hat to fix it) Dear Mr. Schlegel, this bug is going to be fixed in RHEL-6.4. If you require the fix to be released via other channels please escalate this issue through Red Hat Global Support. Best regards, Karel Srot 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. http://rhn.redhat.com/errata/RHBA-2013-0461.html |