Bug 681540

Summary: Using %attr on a directory is does not work correctly if done after %defattr
Product: [Fedora] Fedora Reporter: Bill Pemberton <wfp5p>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: charlieb-fedora-bugzilla, dshaw, ffesti, jnovy, pmatilai, ru
Target Milestone: ---Keywords: Upstream
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 803623 805271 (view as bug list) Environment:
Last Closed: 2012-03-03 16:58:56 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: 803623    
Attachments:
Description Flags
spec file to demonstrate %defattr/%attr proble none

Description Bill Pemberton 2011-03-02 14:22:56 UTC
Created attachment 481875 [details]
spec file to demonstrate %defattr/%attr proble

Description of problem:

The permissions defined by %attr will not get set correctly if the %attr comes after a %defattr.

Version-Release number of selected component (if applicable):
This worked up to Fedora 12, fails in 13, 14, and rawhide.

How reproducible: 100%


Steps to Reproduce:
1) build the attatched .spec file
2) run rpmls -l on the resulting rpm
  
Actual results:
drwxrwxr-x  nobody   nobody   /var/cache/rpmtest/nobody
drwxr-xr-x  nobody   nobody   /var/cache/rpmtest/nobody2


Expected results:
drwxrwxr-x  nobody   nobody   /var/cache/rpmtest/nobody
drwxrwxr-x  nobody   nobody   /var/cache/rpmtest/nobody2

Additional info: 
attached is very simple spec file to demonstrate.

Comment 1 Panu Matilainen 2011-03-25 08:53:03 UTC
Ack, this is a regression originating from fixing bug 515685.

Thanks for the report + reproducer.

Comment 2 Panu Matilainen 2011-06-07 06:50:39 UTC
*** Bug 711226 has been marked as a duplicate of this bug. ***

Comment 3 Panu Matilainen 2011-06-28 10:20:03 UTC
Fixed upstream now.

Comment 4 Daphne Shaw 2011-07-12 19:29:12 UTC
Is this bug the reason for this on F14? (from the filesystem RPM):

# ls -lad /root
dr-xr-x---. 5 root root 4096 May 10 22:12 /root

You'd expect root to have write permissions on its own home directory.

Comment 5 Panu Matilainen 2011-07-13 06:30:12 UTC
That's what the filesystem spec asks for:
%attr(550,root,root) /root

So it appears intentional, git blame points to bug 517575 for the origin of that change. So not related to this bug.

Comment 6 Panu Matilainen 2012-03-03 16:58:56 UTC
Oh well, never got around to fix this in F14 before EOL but it is fixed in F15 and later.

Comment 7 Charlie Brady 2012-03-20 18:39:29 UTC
(In reply to comment #0)

> Expected results:
> drwxrwxr-x  nobody   nobody   /var/cache/rpmtest/nobody
> drwxrwxr-x  nobody   nobody   /var/cache/rpmtest/nobody2

This problem apparently exists in RHEL6:

bash-4.1$ rpm -qlvp rpms/RPMS/i686/rpmtest-0.1-1.el6.i686.rpm
drwxrwxr-x    2 nobody  nobody                      0 Mar 20 14:35 /var/cache/rpmtest/nobody
drwxr-xr-x    2 nobody  nobody                      0 Mar 20 14:35 /var/cache/rpmtest/nobody2
bash-4.1$ rpm -q rpm
rpm-4.8.0-19.el6.i686
bash-4.1$ uname -r
2.6.32-220.4.1.el6.i686
bash-4.1$

Comment 8 Ryan Uber 2013-01-10 03:19:49 UTC
This issue persists in RHEL 6.3
rpm-4.8.0-27.el6.x86_64

Comment 9 Charlie Brady 2013-01-10 03:30:31 UTC
(In reply to comment #3)

> Fixed upstream now.

That's not very helpful to us.(In reply to comment #6)

> Oh well, never got around to fix this in F14 before EOL but it is fixed in
> F15 and later.

Neither is that. :-)

Comment 10 Charlie Brady 2013-01-10 03:32:40 UTC
(In reply to comment #3)

> Fixed upstream now.

If you can identify *where* it is fixed upstream, we can perhaps develop a patch for rpm-4.8.0.

Comment 11 Panu Matilainen 2013-01-10 06:40:36 UTC
This is a bug for EOL Fedora version. The RHEL 6.x counterpart is being tracked in bug 730473 in case you've forgotten...