Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: non-superuser chown(2)s considered harmful
Message-ID: <18802@rpp386.cactus.org>
Date: 11 Dec 90 00:55:26 GMT
References: <18796@rpp386.cactus.org> <660809780.21869@mindcraft.com>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 43
X-Clever-Slogan: Recycle or Die.

In article <660809780.21869@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes:
>In article <18796@rpp386.cactus.org> jfh@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@rpp386.cactus.org