non-superuser chown(2)s considered harmful

[The Grey Wolf]

In article <18821 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
>In article <1990Dec13.204819.17846 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>>In article <1990Dec11.102225.10925 at kithrup.COM> sef at kithrup.COM (Sean Eric Fagan) writes:
>>>Ok. I create a file, for the sole purpose of giving to a friend of mine, who
>>>doesn't happen to be in my group.  Without making the file world-readable
>>>(which I don't want to do for various reasons), how do I let my friend read
>>>it?
>>
>>Encrypt it and give him the key.  Or mail it.
>
>All you are doing is proving the point that root-only chown() makes
>for an administrative nightmare.  Nowhere on the crypt manpage does
>it mention that crypt can be used to change the ownership of a file.
>Mail is pretty much the same story, with the added complexity of
>dealing with binary files.

My only complaint about this is that John, you are throwing in a red herring
here by mentioning chown() and crypt() in the same breath.  The only thing
that Les was suggesting was an alternative to chown.

Here, where we don't have a problem with giving files away (and we are
fortunate enough to have source (which, I understand, unfortunately,
most people don't -- sighhhh)), I just "#ifdef QUOTA"d around the
suser() check.

If you don't have source, a moderately skilled programmer with the knowledge
of the assembly code of the machine he's working on (no big feat) should
be able to patch the routine in the kernel such that the jump to suser()
becomes a string of no-ops.  Not optimal, but it works.

The rest of the restrictions, such as the clearing of the setuid and setgid
bits unless you're the superuser, and the fact that you can't re-acquire a
file unless you're the superuser, are already in place.

>
>If you really want to have a chown that protects the recipient, have
>chown ask for the recipient's password.  Authenticate the luser and
>then do the chown.  Now the chown command can be used to chown files,
>and you don't have to use crypt/mail/uuencode/etc.

This is great.  Except in an environment where quotas are enabled (such as
a university).  I've seen too many instances where a student drops or forgets
to change his/her passwd from the default (SSN), and another student (likely
a group of students) finds (guesses) the password and starts using that
account.  Even when the account goes away, there will be scattered files
which belong to someone else who can no longer be accounted for.  Yeah,
I know, "so use 'find fs -nouser ...'".  The thing is that this headache
should not ever exist in the first place.  In small universities, it works
okay.  In larger ones, the sysads usually have their hands full already.

If quotas are enabled, chown() should be a privileged call.  If they
aren't, then chown() should be available to the world.

>-- 
>John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
>Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org
>"While you are here, your wives and girlfriends are dating handsome American
> movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."


-- 
On the 'Net:  Why are more and more fourth-level wizard(-wannabe)s trying to
invoke ninth-level magic, instead of taking the time to climb the other
(quite essential) thirteen levels so they can do this properly?
...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf