Bug 730473

Summary: %defattr overrides %attr if directory default permission given
Product: Red Hat Enterprise Linux 6 Reporter: Simon Matter <simon.matter>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED ERRATA QA Contact: Patrik Kis <pkis>
Severity: high Docs Contact:
Priority: high    
Version: 6.1CC: charlieb-fedora-bugzilla, ffesti, iperegudov, john.horne, jpazdziora, ksrot, pkis, redhat, schlegel, zbitter
Target Milestone: rcKeywords: 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 Flags
Difference between 4.9.0 and 4.9.1
none
Patch to build/files.c none

Description Simon Matter 2011-08-13 11:08:28 UTC
Description of problem:
I have rebuilt all our source RPMs on EL6 (note the buildhost runs CentOS 6 but with the rpm-4.8.0-16.el6 binaries from RHEL6.1) and found they sometimes
differ in directory permissions compared to those built on EL 3, 4 and
5.

The problem is that %defattr overrides %attr on directories.

Version-Release number of selected component (if applicable):
rpm-4.8.0-16.el6

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
foo

%prep

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

%files
%defattr(0644,root,root,0755)
%attr(0730,root,nobody) %dir /XXX
--%<---------------------------------

Steps to Reproduce:
1. rpmbuild -ba mini.spec
2. rpm -qplv mini-0.1-1.el6.noarch.rpm
3.
  
Actual results:
drwxr-xr-x    2 root    nobody              0 Aug 12 14:19 /XXX

Expected results:
drwx-wx---    2 root    nobody              0 Aug 12 14:16 /XXX

Additional info:
I have asked about this on the CentOS list with 0 reply. It still seems a serious issue to me, because it's security seinsitive. One can assume the resulting rpms are the same like those built on EL5, but that's not the case. The above example show that in certain situations permissions are in fact relaxed, which doesn't look good.

Novell has a BZ entry about this bug:
https://bugzilla.novell.com/show_bug.cgi?id=629048

Did I just miss something or is this really broken?

Thanks,
Simon

Comment 2 RHEL Program Management 2011-10-07 16:04:53 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.

Comment 3 John Horne 2012-03-01 12:01:47 UTC
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.

Comment 4 John Horne 2012-03-01 12:51:10 UTC
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.

Comment 5 Panu Matilainen 2012-03-02 11:18:07 UTC
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.

Comment 6 Panu Matilainen 2012-03-15 10:08:23 UTC
*** Bug 803623 has been marked as a duplicate of this bug. ***

Comment 7 Panu Matilainen 2012-03-20 06:46:12 UTC
*** Bug 804910 has been marked as a duplicate of this bug. ***

Comment 8 Panu Matilainen 2012-03-21 06:15:01 UTC
*** Bug 805271 has been marked as a duplicate of this bug. ***

Comment 9 Charlie Brady 2012-03-21 15:54:38 UTC
(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.

Comment 10 Zane Bitter 2012-03-21 16:59:47 UTC
(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.

Comment 11 Charlie Brady 2012-03-21 20:47:46 UTC
Created attachment 571844 [details]
Difference between 4.9.0 and 4.9.1

Comment 12 Charlie Brady 2012-03-21 20:48:47 UTC
(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.

Comment 13 Charlie Brady 2012-03-21 21:00:18 UTC
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.

Comment 14 Charlie Brady 2012-03-21 21:20:01 UTC
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$

Comment 15 Charlie Brady 2012-03-21 21:22:54 UTC
(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!

Comment 16 Zane Bitter 2012-03-21 21:42:25 UTC
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)

Comment 17 RHEL Program Management 2012-07-10 08:10:35 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 18 Charlie Brady 2012-07-10 12:09:01 UTC
(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.

Comment 19 Panu Matilainen 2012-07-10 12:59:48 UTC
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.

Comment 21 RHEL Program Management 2012-07-11 01:51:51 UTC
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.

Comment 25 Charlie Brady 2012-10-05 12:42:47 UTC
(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.

Comment 26 Karel Srot 2012-10-05 12:50:50 UTC
Hi,
it should be fixed in 6.4.

Comment 27 Charlie Brady 2012-10-05 13:12:59 UTC
Thanks.

Comment 31 Gunther Schlegel 2013-01-15 14:24:46 UTC
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)

Comment 32 Karel Srot 2013-01-15 15:39:25 UTC
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

Comment 34 errata-xmlrpc 2013-02-21 10:51:00 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.

http://rhn.redhat.com/errata/RHBA-2013-0461.html