setperms on linux

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "FilePro Mailing List" <filepro-list at lists.celestial.com>
Sent: Thursday, April 13, 2006 2:12 AM
Subject: Re: setperms on linux


> On Wed, Apr 12, 2006 at 11:11:03PM -0400, J. P. Radley may or may not have
> proven themselves an utter git by pronouncing:
>> >From the 'man chown' page on SCO OSR 6.0.0:
>>
>>    Use of this utility is governed by the chown kernel privilege.
>>    Restricted chown is required for NIST FIPS 151-1 conformance.
>>
>>    If you have chown kernel privilege, you can change the owner and group
>>    of files that you initially own. If you do not have chown privilege,
>>    you cannot change the ownership of files; you can change their group,
>>    but only if the files are initially owned by you, and the new group is
>>    your effective group ID or is listed in your supplemental group list.
>
> Then I suggest you try it on Bob's machine, JP.  That's where I was 
> allowed
> to do it.  Same when it was 5.0.6 before the 5.6 upgrade.  If the kernel
> environment has to be relinked to disallow it, well then it's not secure 
> by
> default, obviously.  My comments would then stand.

Another core-utils developer had this to say. Apparently chown (the 
executable) is not trying to do any chmodding, but the kernel is just doing 
it without asking in chown32 (the system call).
I think what the problem is is previously, and still in other os's, either 
root was treated specially, and/or no-ops were treated specially.
Since the other developer mentioned recently correcting an overoptimization, 
that would fit.
Even if the kernel has been like this a long time, It would still be within 
/bin/chown's power to look at the requested operation and decide it didn't 
even need to call chown32() in the first place, giving the kernel no 
opportunity to do it's thing. In that case, the suid would not be touched.
Now apparently, the binary always calls the system call even for apparent 
no-ops.

Fresh fp installations might be getting the suid bit set correctly despite 
the broken setperms script by virtue of unpacking the tar/cpio, and it's 
just a lucky coincidence that it's always a no-op for those files after 
that, and so the problem never showed itself.

*sigh* it's always something...  :)

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!



-----snip-----
"Brian K. White" <brian at aljex.com> writes:

> chown now clears the suid bit from files it acts upon.

This tends to be a property of the kernel, not of the chown
executable.  You can verify this by running "strace chown user file"
on your GNU/Linux host.  In the example below, the command "chown
eggert at" executed the chown32 system call as requested, but the
kernel decided to clear the setuid bit.  Hence the bug (if there is
one) is in the kernel, not in coreutils.

penguin:/tmp# pwd
/tmp
penguin:/tmp# cp -p /usr/bin/at .
penguin:/tmp# ls -l at
-rwsr-xr-x  1 root root 34488 Jan 18  2002 at
penguin:/tmp# strace -o tr chown eggert at
penguin:/tmp# tail tr
munmap(0x40018000, 1130)                = 0
close(3)                                = 0
lstat64("at", {st_mode=S_IFREG|S_ISUID|0755, st_size=34488, ...}) = 0
open(".", O_RDONLY|O_NONBLOCK|O_NOCTTY|O_LARGEFILE|O_DIRECTORY) = 3
fchdir(3)                               = 0
chown32("at", 1000, -1)                 = 0
fchdir(3)                               = 0
close(3)                                = 0
close(1)                                = 0
exit_group(0)                           = ?
penguin:/tmp# ls -l at
-rwxr-xr-x  1 eggert root 34488 Jan 18  2002 at
-----snip-----