Re: chown clears suid bit!

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please keep replies on the list, so that others may see the resolution or
chime in with further ideas.

According to Brian K. White on 4/12/2006 10:41 PM:
>>
>>  Several fixes to chgrp and chown for compatibility with POSIX and BSD:
>>
>>    Do not optimize away the chown() system call when the file's owner
>>    and group already have the desired value.  This optimization was
>>    incorrect, as it failed to update the last-changed time and reset
>>    special permission bits, as POSIX requires.
> 
> That all makes sense, but, I'm logged in as root.
> I am manipulating files owned by not-root. Is that supposed to be enough
> to trigger it?

As far as I can see, the source code for chown(1) does not call chmod(2),
only chown(2).  So if the special bits are being reset, even when you are
root, then it is a kernel issue with chown(2) and you might be better off
asking on a kernel list why they chose to strip special bits even for
root.  In the case of a privileged process, POSIX documents that behavior
as implementation-defined,
http://www.opengroup.org/onlinepubs/009695399/functions/chown.html:

If the specified file is a regular file, one or more of the S_IXUSR,
S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does
not have appropriate privileges, the set-user-ID (S_ISUID) and
set-group-ID (S_ISGID) bits of the file mode shall be cleared upon
successful return from chown(). If the specified file is a regular file,
one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are
set, and the process has appropriate privileges, it is
implementation-defined whether the set-user-ID and set-group-ID bits are
altered. If the chown() function is successfully invoked on a file that is
not a regular file and one or more of the S_IXUSR, S_IXGRP, or S_IXOTH
bits of the file mode are set, the set-user-ID and set-group-ID bits may
be cleared.

> 
> And yes, in this case, usually the owner & group don't actually change,
> in fact nothing is supposed to change since the script just consults a
> list of files and their desired modes & ownerships, and runs chmod/chown
> a bunch of times, and mostly all the files are already supposed to be
> correct so in the end nothing happens. So perhaps that is why this has
> never been a problem before, most of the time action was optimized away?
> I would have thought such a no-op would be fine, even from a security
> point of view. Making a change when no change is expected is not
> principle of least surprise.

You are welcome to file a change request to the Austin group, with
proposed wording to rectify this situation to something that is less
surprising when neither owner nor group change.

> 
> In fact, it could be a security problem this way too.
> Imagine a public daemon or binary that is suid not-root for safety, so
> that even when root_or_other_hi_priv_user runs it, it still lacks power.
> Suddenly it loses suid due to a chown that should have been a no-op, and
> now runs as root_or_other_hi_priv_user, istead of nobody or guest or lp
> etc...
> 
> Thanks for your attention.
> The database authors have already decided the right thing to do is fix
> the script to run chown before chmod in all cases, and I've fixed my own
> the same way so I'm fine now and I appreciate the response.

Indeed, the safest response when manipulating suid files as root is to
check their permissions after the fact to ensure they are still what is
desired.  With great power comes great responsibility.  You may also want
to update your script to call chmod before, as well as after, chown, so
that there is no window of time where the new owner can use the file with
the old permissions that are about to be stripped by the new permissions.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPkPZ84KuGfSFAYARAqnkAJ0Zy5E21Bov1M5pSX5b9BVKcC7PoACgvUgm
Q3RTLprd4nirhyelNP6XaFI=
=LWK1
-----END PGP SIGNATURE-----