Date: Tue, 9 Jul 1996 22:38:09 -0700 From: "M.R.Murphy" <mrm@MARMOT.Mole.ORG> To: bde@zeta.org.au Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) Message-ID: <199607100538.WAA29432@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
>
> >> attributes. I now think it should refuse to the move if it can't
> >> preserve all the attributes. It can simply unlink the target and
> >> avoid unlinking the source if there is a problem.
>
> >Or, one could leave it as it is, and accept the known, rather predictable,
> >and simple behavior instead of a more complicated and unknown behavior.
What I wrote sure sounds harsh. I didn't mean for it to be. My wife says
I'm a churlish lout.
>
> To predict the behaviour, you need to know if the move is across file
> systems and the current bugs in mv. Only mv's within a file system
> are predictable.
Yes. This is painful.
>
> Another bug in mv:
>
> touch /tmp/z
> chflags uchg /tmp/z
> mv /tmp/z /tmp/z1 # Fails as expected
> mv /tmp/z ~ # Copies the file to ~/z, then fails to
> # unlink ~/z, leaving two copies of the
> # file, one without the uchg flag.
>
> If mv happens to use `cp -pRP' (which it does for everything except regular
> files) then the result is similar. cp knows about file flags and sets the
> uchg flag in the copy, except of course if the target file system doesn't
> support the uchg file flag.
>
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).
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.
2) user mrm can chgrp /tmp/xyz to group home or wheel.
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.
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.
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.
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,
a program I was never too fond of. I haven't been too fond of the BSD
behavior of sticking group in a directory, either. It's tolerable, but
not too desirable, I think.
NO giving away a file through chown. root can do anything.
Does this make sense? I hope so. Is this poorly stated? Yes. Should
it be moved from bugs? Almost certainly. Is it so untraditional that
it could never be? Probably.
--
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?199607100538.WAA29432>