chown broken in 3.1 ?

[Guy Harris]

>I can see where this might fix some serious security holes inherent with
>remote file systems, but does the rest of the world do this?

A lot of the rest of the world *does* do this.

The original Research versions of UNIX worked that way; as one of the V6
or V7 man pages said, this was done to prevent attempts to defeat the
"(non-existent) disk space accounting procedures".  BSD preserved this
behavior, and SunOS (definitely) and Ultrix (probably), to name a couple
of systems, preserved it as well.

PWB/UNIX 1.0, as I remember, made "chown" not quite so privileged,
allowing a process to "give away" files that belonged to its effective
UID.  This propagated into S3 and S5.

I seem to remember hearing that AIX 3.1 supports disk quotas (BSD-style
ones, it seems); they may have made "chown" require root privilege in
order to prevent attempts to defeat the (no longer non-existent) disk
space accounting procedures.  If so, it's in the same boat as, for
example, System V Release 4, which has a configuration option to make
"chown" require root privileges, so that you can't defeat the quotas
that the BSD file system in S5R4 supports.

>Or is this another one of IBM's better ideas?  I am open to suggestions on
>how to work around this, although I'm not very open to having the entire
>RCS package run suid root.

I assume you have some reason why "co" needs to run set-UID at all.  As
such, what you *might* want to do (if you have source to RCS) is change
it so that it temporarily gives up its set-UID privileges when it
creates files that should be owned by the user running "co", and then
reclaims them when necessary (I assume AIX has the "saved set-user ID"
notion; I would be surprised if it didn't).