non-superuser chown(2)s considered harmful
John F Haugh II
jfh at rpp386.cactus.org
Tue Dec 11 11:55:26 AEST 1990
In article <660809780.21869 at mindcraft.com> karish at mindcraft.com (Chuck Karish) writes:
>In article <18796 at rpp386.cactus.org> jfh at rpp386.cactus.org
>>User's should not be forced to contact an administrator, or perform file
>>access mode mumbo-jumbo to give a file away.
>
>This surprises me a little. I'd thought that the most militant
>computer freedom zealots were BSD types.
Having spent several years as the senior staff person on large
business systems has mellowed certain aspects of my computer
personality ;-)
The statement really does come from years of experience with
users asking how to give away [ or take back ;-( ] files.
>Anyway, changing a file's ownership isn't necessary for sharing.
>Changing its ownership handicaps the previous owner's access just
>as it enhances the new owner's access. Group access is the
>right way to share files. This is implemented in a reasonable
>way in BSD systems, but the POSIX.1/FIPS 151-1 translation is
>flawed, as I've pointed out here before.
In a sense you are correct - really "sharing" a file does not
require giving the file away, but from a practical standpoint
you are still wrong. For =well behaved= applications concurrent
group sets do help out, but many applications are not careful
with how they create new files, etc. As a user who is
"sharing" his files, if I set my umask to 027 (which it often
is), I've just made sure I'm "read-only" sharing my files in
most cases. And in practice, this is exactly what happens when
dozens of non-UNIX literate users start messing around with
UNIX commands.
>>Why FIPS went with chown() being restricted is a mystery ...
>
>Hint: FIPS 151-1 also requires that NGROUPS_MAX be non-zero.
Well, Doug Steves (of POSIX 1003.6 & IBM fame) and I joked
around about concurrent user sets. Personally, I like that
idea much better ;-)
--
John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 Domain: jfh at rpp386.cactus.org
More information about the Comp.unix.internals
mailing list