I do a large number of local mock builds as a part of the package reviews that I do, and one problem I consistently run into is executables and .so files coming out with mode 775, but a scratch build in Fedora's koji instance showing the expected 755 permissions.
I thought it might be some local environment leaking into my mock builds, but my personal umask is 022 which should be OK and changing it doesn't alter the result anyway.
Init'ing a fresh chroot shows the default umask in it is 0002, which would seem to explain things but wouldn't explain why the Fedora buildsys has different results. Is there customization done there to force the umask somehow?
- J<
Jason L Tibbitts III wrote:
I do a large number of local mock builds as a part of the package reviews that I do, and one problem I consistently run into is executables and .so files coming out with mode 775, but a scratch build in Fedora's koji instance showing the expected 755 permissions.
I thought it might be some local environment leaking into my mock builds, but my personal umask is 022 which should be OK and changing it doesn't alter the result anyway.
Init'ing a fresh chroot shows the default umask in it is 0002, which would seem to explain things but wouldn't explain why the Fedora buildsys has different results. Is there customization done there to force the umask somehow?
I believe the umask needs to be 002 in order for users in the mock group to be able to use mock effectively.
Regardless, if this is affecting your rpms, then your specs are probably broken. Use %defattr in all %files sections.
"MM" == Mike McLean mikem@redhat.com writes:
MM> I believe the umask needs to be 002 in order for users in the mock MM> group to be able to use mock effectively.
Which umask? My person one? If mock requires a specific umask value, it should simply set one itself.
MM> Regardless, if this is affecting your rpms, then your specs are MM> probably broken. Use %defattr in all %files sections.
You'll note that I mentioned that I do many package reviews; these aren't my rpms. Also, %defattr is present in the packages I have seen to have this problem. (Fedora guidelines mandate it.) Is there some specific %defattr value you suggest? "(-.root,root,-)" is quite common.
- J<
On Sun, 2008-11-09 at 22:26 -0600, Jason L Tibbitts III wrote:
"(-.root,root,-)" is quite
I do believe that sets it to "whatever owner permissions the file has on the filesystem, root owner, root group, whatever group permissions it has on the filesystem" or something close to that effect. In other words, it's forcing ownership, but not permissions.
On Sun, 2008-11-09 at 23:48 -0800, Jesse Keating wrote:
On Sun, 2008-11-09 at 22:26 -0600, Jason L Tibbitts III wrote:
"(-.root,root,-)" is quite
I do believe that sets it to "whatever owner permissions the file has on the filesystem, root owner, root group, whatever group permissions it has on the filesystem" or something close to that effect. In other words, it's forcing ownership, but not permissions.
(file permissions, user ownership, group ownership, directory permissions)
On Mon, 2008-11-10 at 03:08 -0500, Ignacio Vazquez-Abrams wrote:
(file permissions, user ownership, group ownership, directory permissions)
That's what I get for answering something after midnight without looking it up in the manual. Thanks!
"JK" == Jesse Keating jkeating@redhat.com writes:
JK> I do believe that sets it to "whatever owner permissions the file JK> has on the filesystem, root owner, root group, whatever group JK> permissions it has on the filesystem" or something close to that JK> effect.
Well, yes, but obviously (755,root,root,755) doesn't work all that well, because then all files are executable. (-,root,root,755) would be OK, I guess, but of course that wouldn't have any bearing on the problem I'm seeing.
- J<
On Mon, 2008-11-10 at 08:14 -0600, Jason L Tibbitts III wrote:
Well, yes, but obviously (755,root,root,755) doesn't work all that well, because then all files are executable. (-,root,root,755) would be OK, I guess, but of course that wouldn't have any bearing on the problem I'm seeing.
IIRC you can have multiple defatters that you can use per-file for ultimate control over the permissions/ownership of each individual file. Most packages don't do this, and instead set permissions at the %install stage, either by how they call /usr/bin/install or by settings in makefiles for make install.
Jason L Tibbitts III wrote:
"MM" == Mike McLean mikem@redhat.com writes:
MM> I believe the umask needs to be 002 in order for users in the mock MM> group to be able to use mock effectively.
Which umask? My person one? If mock requires a specific umask value, it should simply set one itself.
It does. mock calls os.umask(002) at startup (and has for a while). The mock on the Fedora build hosts has this line. I'm not sure why you're seeing a difference. Can you point to a specific Fedora build whose results differ from what you get locally?
MM> Regardless, if this is affecting your rpms, then your specs are MM> probably broken. Use %defattr in all %files sections.
You'll note that I mentioned that I do many package reviews; these aren't my rpms. Also, %defattr is present in the packages I have seen to have this problem. (Fedora guidelines mandate it.) Is there some specific %defattr value you suggest? "(-.root,root,-)" is quite common.
Sorry, I guess it gets a bit more complicated with modes. Jesse's comments seem dead-on. If you don't want to patch the package to have it install with proper modes, then you can work around it with multiple %defattr() macros and/or per-file %attr() macros
"MM" == Mike McLean mikem@redhat.com writes:
MM> It does. mock calls os.umask(002) at startup (and has for a MM> while). The mock on the Fedora build hosts has this line. I'm not MM> sure why you're seeing a difference. Can you point to a specific MM> Fedora build whose results differ from what you get locally?
Here's a package from a recent review: http://www.math.uh.edu/~tibbs/rpms/cave9-0.3-2.bog9.src.rpm
When build locally, the included file /usr/bin/cave9 has mode 0775. When built in koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=924911) the file has mode 0755.
My local machine has mock-0.9.9-1.fc9.noarch. I am using the caching stuff, and my configuration files have been modified to point to local package mirrors and to set basedir to /mock which is a 10G tmpfs with the same permissions as /var/lib/mock. Those permissions happen to be 2775; that's probably coincidental but I guess you never know.
- J<
On Mon, 2008-11-10 at 12:32 -0600, Jason L Tibbitts III wrote:
Here's a package from a recent review: http://www.math.uh.edu/~tibbs/rpms/cave9-0.3-2.bog9.src.rpm
When build locally, the included file /usr/bin/cave9 has mode 0775. When built in koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=924911) the file has mode 0755.
My local machine has mock-0.9.9-1.fc9.noarch. I am using the caching stuff, and my configuration files have been modified to point to local package mirrors and to set basedir to /mock which is a 10G tmpfs with the same permissions as /var/lib/mock. Those permissions happen to be 2775; that's probably coincidental but I guess you never know.
I think the main point to take away from this is that relying on umask of systems to set the permissions of your files correctly is fragile at best, dangerous at worst. Umask can and does change from host to host so the build output is unreliable. Permissions in package builds should be set explicitly at either the %install phase or the %files phase. This likely needs a big sweeping cleanup action on our existing packages, but catching this on new packages is a start.
buildsys@lists.fedoraproject.org
-
Ignacio Vazquez-Abrams -
Jason L Tibbitts III -
Jesse Keating -
Mike McLean