Bug 681540 - Using %attr on a directory is does not work correctly if done after %defattr
Summary: Using %attr on a directory is does not work correctly if done after %defattr
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 14
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 711226 (view as bug list)
Depends On:
Blocks: 803623
TreeView+ depends on / blocked
 
Reported: 2011-03-02 14:22 UTC by Bill Pemberton
Modified: 2013-01-10 06:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 803623 805271 (view as bug list)
Environment:
Last Closed: 2012-03-03 16:58:56 UTC


Attachments (Terms of Use)
spec file to demonstrate %defattr/%attr proble (805 bytes, application/octet-stream)
2011-03-02 14:22 UTC, Bill Pemberton
no flags Details

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


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