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 purpose.
Created attachment 100963 [details] Proposed patch
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.)
Michael, 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 RPMs. 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 (-,root,root) though...
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 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.
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 ? Thanks.
It is still an issue -devel, i think a %srcdefattr is very usefull anyway. Please have a look to our issue: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195954 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 4.4.2.1
Fixed in next rawhide push by rpm 4.4.2.1-rc1