Red Hat Bugzilla – Bug 125515
[patch] New _srcdefattr macro (so src.rpm files aren't owned by builder)
Last modified: 2007-11-30 17:10:44 EST
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
Created attachment 100963 [details]
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.
Hmm, bugzilla doesn't allow me to change the status away from NEEDINFO. Is
this the intended behaviour?
(Bug status gets changed away from NEEDINFO automatically.)
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?
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.
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?
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
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'.
I prefer my patch as this is a policy issue and I like to be able to configure
the policy used.
(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
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.
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 ?
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 ?
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.
still a bug.
Thanks Balint. Yes indeed.
This is now applied to rpm.org tree, will be in rpm 220.127.116.11
Fixed in next rawhide push by rpm 18.104.22.168-rc1