non-superuser chown(2)s considered harmful

[Neil Rickert]

In article <18792 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
>In article <1990Dec7.171501.18028 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil Rickert) writes:
>> What do you mean by 'support chown()'.  Should another field be added
>>to the 'inode' specifying the 'real owner' to be used for permissions,
>>and chown() by other than root preserves this 'real owner' field.  This is
>>adding too much complexity.  Disallowing non-root access to chown() is
>>simpler, more effective, and safer.
>
>The context of the thread was that chown() messes up the quota mechanism,
>and is therefore evil.  This is the common excuse, and is often used as
>the justification for BSD not supporting non-root chown().
>
>However, this is silly.  If the system can properly maintain quotas
>with open/creat and unlink calls being made, there is no reason it
>cannot properly maintain quotas with chown() system calls.
>
 Why do you completely misinterpret what people are saying.  The problem
with quotas and non-root chown is that the file is charged against the
new owner, and the ability to chown allows one to circumvent limits applied.

 Any different meaning of quotas would mean that the system would have to
read the system administrator's mind as to who should be charged for the
file space.
>
>The result of making a system call "root-only" is that any application
>which might have a legitimate need to execute that function must be
>set-uid to root in order to perform that now privileged operation.
>For example, if all the unallocated TTY devices were owned by "uucp",
>all the applications which deal with TTY devices would only have to
>be set-UID to "uucp".  Unfortunately, if you have an application that
>wants to change the ownership to the user, such as cu, you must now
>make cu set-UID to "root".

 Non superuser chown() doesn't solve this problem.  It at best provides a
half-baked solution, for it can leave the user owning the TTY and uucp
being able to reclaim it.

 A better solution here would be to have a way of changing the ownership
of the TTY only on the in-memory copy of the inode, but never writing
this changed ownership back to disk.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert at cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115.                                  +1-815-753-6940