Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.internals
Subject: Re: non-superuser chown(2)s considered harmful
Message-ID: <1990Dec17.063448.556@chinet.chi.il.us>
Date: 17 Dec 90 06:34:48 GMT
References: <1990Dec11.102225.10925@kithrup.COM> <1990Dec13.204819.17846@chinet.chi.il.us> <18821@rpp386.cactus.org>
Organization: Chinet - Public Access UNIX
Lines: 41

In article <18821@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
>>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.

Encryption provides the advantage of also protecting you from casual
browsing by the administrator while allowing ownership to be changed
the "right" way (i.e. by leaving the file readable so that the new
owner can make his own copy).

>Mail is pretty much the same story, with the added complexity of
>dealing with binary files.

Yes, of course mail should be fixed allow attachments.  Mine is, using
a combination of AT&T's PMX mail UA's and smail 3.1.  My users generally
don't know (or need to know) who is on the same machine with them.
All they need is the mail alias to share files.  End of problem.
 
>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.

Umm, we've already got that under the guise of "su".  And, this would
require you to know someone's password to send them mail if your
mailer runs setgid instead of setuid root.  The main thing that I
object to about chown is that it prevents sensible security checks
from working that could otherwise help setuid root programs decide
who created a file.  For example, a mailer wanting to execute a pipe
in a .forward file might be able to tell who created that file.  As
things are, it has to check the directory for write permission (and
hope those permissions applied when the file was created) and can
be fooled by other programs that use special permissions to create files
that look like they belong to you.   Maybe requiring the setuid bit to
be set on these files would work, though, since chown is supposed to
clear that.

Les Mikesell
  les@chinet.chi.il.us