Date: Wed, 10 Jul 1996 06:44:02 -0700 From: "M.R.Murphy" <mrm@MARMOT.Mole.ORG> To: bde@zeta.org.au, mrm@mole.Mole.ORG Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) Message-ID: <199607101344.GAA00726@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
> >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. I think that the world-writable directory imposing group is the real problem here (as you say below). What's reasonable to do about it? > > >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. Me too. Too big a change, even though it's equivalently simple compared to the *BSD behavior. That is, creator determines group vs. directory determines group. Would it be too big a change for creator determines group if the directory is world writable? I think that'd fix the problem that we (maybe not we, maybe just me?) now see with /tmp. Is that the equivalent of what you meant by "not use BSD gid semantics if the resulting gid couldn't be set by the user directly"? No, I think it isn't. If the user were in group bin and the directory was group bin, then the group of the created file would be bin. Otherwise, it would be the user's group. I'd prefer for it to just be the user's group if the directory is world writable. Bad? [...] > > >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. If files created in /tmp have your real gid and you move the file to the project dir and the real gid is not suitable for the project, then you ought to change the group of the file to the project group either before or after moving it to the project dir, no? That you can move the file to the project dir means that you can do the chgrp, right? -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607101344.GAA00726>