From owner-freebsd-bugs Wed Jul 10 00:40:11 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18469 for bugs-outgoing; Wed, 10 Jul 1996 00:40:11 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18321 for ; Wed, 10 Jul 1996 00:40:00 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA30946; Wed, 10 Jul 1996 17:36:01 +1000 Date: Wed, 10 Jul 1996 17:36:01 +1000 From: Bruce Evans Message-Id: <199607100736.RAA30946@godzilla.zeta.org.au> To: bde@zeta.org.au, mrm@MARMOT.Mole.ORG Subject: Re: bin/1375: Extraneous warning from mv(1) Cc: freebsd-bugs@freefall.freebsd.org Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I have a suggestion that I'd like to have shot down. Or amplified. It's >heretical in that it doesn't follow tradition. Suppose the following: > 1) a directory, say /tmp owned by bin, group bin, writable. > 2) a user, say mrm, uid=101(mrm) gid=200(home) groups=200(home), 0(wheel). Aha! The point is that so files shouldn't default to having group bin except in the misconfigured case when the user is in group bin. Users normally can't write to directories that they don't have group access to, but there is a problem for world-writable (probably sticky) directories. I propose to not use BSD gid semantics if the resulting gid couldn't be set by the user directly. >Then file creation, cp, mv, chmod, chgrp might well behave as > 1) cd /tmp; :>xyz would result in xyz owned by mrm, group home, > rather than owned by mrm, group bin, that is, not like present > *BSD behavior. Like System V, group and owner of newly created > file is determined by uid, gid of creator, not by containing directory. I think this is too large a change. > 2) user mrm can chgrp /tmp/xyz to group home or wheel. Works already. > 3) user mrm can then mv or cp /tmp/xyz to somewhere else legal, i.e., > writable directory, with attributes maintained if legal, so that, > for example, a mv of an sgid file leaves it sgid iff the group is > one to which the user belongs. mv and cp leave group alone if > it's one to which the mover or copier belongs. Works already except when the user doesn't have permission to change the source gid. > 4) chgrp leaves other attributes as-is if the chgrp is legal. This means > that, for user mrm as above, > % cd /tmp; :>xyz; chmod 2775 xyz; chgrp wheel xyz; mv xyz ~ > ends up with xyz owned by mrm, group wheel, and sgid in mrm's > home directory. Not the sequence of errors that now occurs. No, the chmod is an error because you're not in group bin. Reversing the chmod and the chgrp works now, and the above sequence works if the initial gid is reasonable. > 5) a file in a writable directory belonging to another user and > moved or copied by mrm would end up belonging to mrm, no matter > whether the destination was on the same or a different file system. > The group would remain the same if it was a group to which mrm > belonged, and would change to the gid of mrm if not. This would make mv too different from rename() and it is too late to change rename(). >Does this make workgroups of users reasonable? I think so. Users user1, >user2, and user3 could all belong to group projectA, even if they >were of different gid and effectively work on projectA if they >chgrp as required. I don't think it requires the System V newgrp, either, I think there is a problem with stuff created in /tmp and mv'ed to a project directory. Now it has gid bin in /tmp and the project directory's gid when it is mv'ed. The chgrp to bin has to fail for the correct gid to be preserved. (BTW, patch screws up gids iff it is run by root because the chgrp _doesn't_ fail for root. It creates temporary files in /tmp and then mv's them to the final (patched) file. It actually uses an internal version of mv.) If files created in /tmp have your real gid, then mv would have to be careful not to preserve it when mv'ing to a project dir, since the real gid is not always suitable for projects. Bruce