Bug 125515 - [patch] New _srcdefattr macro (so src.rpm files aren't owned by builder)
Summary: [patch] New _srcdefattr macro (so src.rpm files aren't owned by builder)
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Keywords: Patch
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-08 13:48 UTC by Michael Schröder
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2007-06-26 07:52:32 UTC

Attachments (Terms of Use)
Proposed patch (1.68 KB, patch)
2004-06-08 13:49 UTC, Michael Schröder
no flags Details | Diff
Fixes security compromise (411 bytes, patch)
2006-05-11 15:42 UTC, Sergey Yanovich
no flags Details | Diff

Description Michael Schröder 2004-06-08 13:48:49 UTC
When building as not-root user it is nice to specify default 
attributes for the source rpm (like with %defattr). This patch 
adds a new macro %_srcdefattr which can be used for this 

Comment 1 Michael Schröder 2004-06-08 13:49:26 UTC
Created attachment 100963 [details]
Proposed patch

Comment 2 Matthew Miller 2005-04-26 16:12:15 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 3 Michael Schröder 2005-04-26 16:29:54 UTC
Hmm, bugzilla doesn't allow me to change the status away from NEEDINFO. Is 
this the intended behaviour? 

Comment 4 Matthew Miller 2005-04-26 17:46:33 UTC
(Bug status gets changed away from NEEDINFO automatically.)

Comment 5 Paul Nasrat 2005-04-26 21:03:23 UTC

Is this for the case of determining modes for source files in src.rpm?  uid/gid
gets squashed on non-root install of src.rpm so I assume it's just if you sucked
in a src file with unexpected perms (probably umask).

Eg rpmlint complains about 664 based src's in srpms?

Comment 6 Michael Schröder 2005-04-27 10:08:16 UTC
It's actually for setting the owner/group. We build our rpms with a special 
user "abuild". I a customer installs the src rpm as user root, he will 
get a "user abuild does not exist" warning. This is a minor issue, of course. 

Comment 7 Matthew Miller 2005-04-27 12:25:43 UTC
I think a better fix would be for RPM to just suppress that message for source

Or just automatically make all files in source rpms effectively owned by
"nobody" with mode 644 (and maybe allow 755) -- is there really a case where
anyone would want anything else?

Comment 8 Michael Schröder 2005-04-27 12:52:44 UTC
That's exactly what the patch does. One can put _srcdefattr (-,nobody,nobody) 
into /usr/lib/rpm/macros and all sources will be owned by nobody. I prefer 
(-,root,root) though... 

Comment 9 Sergey Yanovich 2006-05-11 15:42:35 UTC
Created attachment 128898 [details]
Fixes security compromise

Please note, that current rpm behavior seriously compromises security on the
machine used to build srpm. Simple ârpm -qplvi 'package-name'â will tell
anyone, who has the package, an existing user name, an existing group name, and
the host name of that machine. You can see that the net is flooded with
complains of those who has encountered typical rpm warning (user/group does not
exists â using root).

Personally, I never build packages as root, but always use root as the only
possible owner of files in srpms. This hasn't caused any problem. If the source
files are owned by root in a srpm, rpm installs them using invoker's uid and
gid. You just to change two line in 'build/files.c'.

Comment 10 Michael Schröder 2006-05-11 15:59:48 UTC
I prefer my patch as this is a policy issue and I like to be able to configure 
the policy used. 

Comment 11 Sergey Yanovich 2006-05-11 16:18:52 UTC
(In reply to comment #10)
> I prefer my patch as this is a policy issue and I like to be able to configure 
> the policy used. 

It is reasonable, please just add something like (-,root,root) to the default
macro file.

The issue is that your patch has not been incorporated in the distribution, over
a year since it was filed. For all this time sensitive information is released
by people some of whom are not even aware. You may think about raising severity
of your bug.

Comment 12 Christian Iseli 2007-01-22 11:15:32 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?


Comment 13 Balint Cristian 2007-01-30 18:49:04 UTC
It is still an issue -devel, i think a %srcdefattr is very usefull anyway.

Please have a look to our issue:
I would like to fix this issue of mock with adding to one mock jailed .macro 
file the %srcdefattr macro only, rather than do an ugly hack inside mock. As 
remainder mock build in chroot env so its hard to workaround.

What do you think ?

Comment 14 Matthew Miller 2007-04-06 15:24:19 UTC
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest
this issue on a current release or on the latest development / test version, we
would appreciate that. Otherwise, this bug will be marked as CANTFIX one month
from now. Thanks for your help and for your patience.

Comment 15 Balint Cristian 2007-04-06 15:45:34 UTC
still a bug.

Comment 16 Matthew Miller 2007-04-06 15:52:34 UTC
Thanks Balint. Yes indeed.

Comment 17 Panu Matilainen 2007-06-11 06:32:52 UTC
This is now applied to rpm.org tree, will be in rpm

Comment 18 Panu Matilainen 2007-06-26 07:52:32 UTC
Fixed in next rawhide push by rpm 

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