Date: Mon, 31 Jul 1995 08:05:36 -0400 From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: bde@zeta.org.au, zeta.org.au!bde@dg-rtp.dg.com, freebsd-bugs@FreeBSD.org, freebsd-hackers@FreeBSD.org, ponds!rivers, ponds!rivers@zeta.org.au Subject: Re: Problem with /bin/mv on 2.0.5. Message-ID: <199507311205.IAA09296@lakes>
next in thread | raw e-mail | index | archive | help
> > > 1) The owner of all the files/directories is 'user'; there group id > > of all the files/directories is the same, and is 'user'. > > /tmp has group bin unless you've changed the default. > > > 2) This operated "correctly" at 1.1.5 and 2.0 - that is, no message > > was generated when the 'mv' occured. > > > 3) The source for 'mv' hasn't changed from 2.0 to 2.0.5; so I don't > > think that would be a fruitful place to look. > > > 4) /tmp is a different file system from /usr, and I have always done > > that (that is, in my 2.0 system, /tmp was a different file system.) > > Perhaps /tmp had the wrong group in 2.0. Well - working on that theory; and the obviously (now that I think about it) conclusion that the problem must be changing the group (as Bruce had already deduced) - I did the following: $ su # cd /tmp # chgrp general . "general" is the user's group. # exit $ cd /tmp $ touch t $ mv t /usr/user/N and, sure enough - I got no message; and the file /usr/user/N/t was: -rw-r--r-- 1 rivers general 0 Jul 31 07:58 t Now, when I put the group ownership of /tmp back to its proper 'bin' ownership and do the same operation (so that I get group as the owner of 't') as in: Script started on Mon Jul 31 08:00:00 1995 $ cd /tmp $ touch t $ ls -l t -rw-r--r-- 1 user bin 0 Jul 31 08:00 t $ rm $HOME/N/t $ mv t $HOME/N/t mv: /usr/user/N/t: set owner/group: Operation not permitted $ ls -l $HOME/N/t -rw-r--r-- 1 user general 0 Jul 31 08:00 /usr/user/N/t $ ^D Script done on Mon Jul 31 08:00:35 1995 So, we see that the file in /tmp was (after it was created with touch) in the group 'bin'. And, after the move (across file systems) it was in the "correct" group 'general' - the user's group. (Probably because the user "user" had to create and copy the file to move it across file systems. Is it possible that fchown shouldn't complain when the group being set is the one the file actually (probably by happen-stance) has? Also, Bruce has an equally viable alternative suggestion below... > > > I think the problem is the fchown() is being more aggressive at checking > >in 2.0.5 than it did at 2.0 - possible more so than is correct. > > No. It was more agressive in 2.0. It is correct for it to report changes > that can't be made as errors. > > Perhaps mv should be quieter about such changes. I think it should > report uid and mode changes but not gid changes for the case here > (moving by non-root from a sticky public dir) where it is known that > preserving the gid is impossible. The uid may be lost for moves from a > non-sticky public dir. The mode may be lost for moves of sticky dirs > (e.g., by cp and mv fail to preserve the sticky bit when /tmp is `cp > -pR'ed. This bug would have been more obvious if the mode was checked). > > Bruce >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507311205.IAA09296>