chown (was: at files and permissions)

[James Ellis]

In article <34422 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
>From: gwyn at smoke.BRL.MIL (Doug Gwyn)
>>use of "du|sort -rn" to find where the problems are.
>...
>No, it can't be dealt with with "du|sort -rn" except on very small systems

With respect to disk quotas, certainly the du mechanism works well for
those environments that can survive with motd or mailed warnings.
(Actually, I prefer a du or ls -R that divides by the number of links
to the file.  But same idea.)  If you have users that ignore you then
you either need policy sanctions or dynamic quotas built into the kernel.
This is all clear enough - I'm sure Doug doesn't need to be lectured
about how to run large systems.

In article <4884 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>I certainly hope that V.4 doesn't have this *bogus* restriction.
>...

But what is this fascination System V has with chown?
It seems to me to be a security problem begging to be misused.
I'll admit that a wide-open chown can make life easier for a few
system utilities - I know how hard it is to write a secure setuid program -
but do not believe these wins outweigh the problems with users being
able to give away files.

When I own a file, I have responsibility for it, and I do not like for
users to be able to foist that responsibility upon me without my knowledge.

If Doug needs to change file ownerships often then he should have his
setuid program that checks and logs what he's doing.
So.  Are there other solutions provided by wide-open chown?
(That's your cue, Peter.)

I'll summarize replies to me; replies to the net summarize themselves...

				-- Jim Ellis