Date: 09 Jul 1996 04:28:24 -0500 From: Zach Heilig <zach@blizzard.gaffaneys.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: James Raynard <fqueries@jraynard.demon.co.uk>, freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: What's up with ownership? Message-ID: <873f31ai87.fsf@freebsd.gaffaneys.com> In-Reply-To: Garrett Wollman's message of Mon, 8 Jul 1996 11:00:39 -0400 References: <87n31da1pa.fsf@freebsd.gaffaneys.com> <199607062246.WAA03437@jraynard.demon.co.uk> <9607081500.AA03598@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman <wollman@lcs.mit.edu> writes: > It's worth explaining why this is the Right Thing. Say John and Jane > are working on a project together. To make file-sharing easier, they > create a group, `jjproj', and a directory, `/home/jjproj', mode > ug=rwx,o=rx, owner `root', group `jjproj', and agree to use a umask of > 002. My real problem isn't with files being created with a gid the same as the parent directory, at least after I thought it through a bit. It is really with an extraneous warning from mv(1) while trying to preserve that gid (which, in this case, you are not a member of) in some other directory. The only time I think it would be appropriate for mv(1) to complain that it can't preserve the gid is when either the group write and/or setgid bits are set. It should complain about not preserving the uid when the setuid bit is set. In either case, neither the setuid or the setgid bits should be preserved. mv(1) will currently retain the setuid bit no matter what the situation. > Consider by contrast the BSD model. John creates `/home/jjproj/foo', > and it automatically belongs to the same group as is able to write to > the `/home/jjproj' directory in the first place, which is exactly the > right thing. Rather than introduce warts to selectively enable this > behavior depending on some random selection of circumstances, BSD > simply applies this model consistently throughout the filesystem, even > in places where it is not obviously useful. The problem, I think, is really mv, not the system. BTW, I did find a real bug in mv, and a potential security hole (which is why I cross-mailed it to security). I think this only works if the two directories are on different filesystems. Try this on your machine: Script started on Tue Jul 9 03:50:45 1996 $ whoami user1 $ pwd /usr/home/user1 $ mkdir foo $ chmod 777 foo $ cd foo $ touch bar $ chmod 6755 bar $ ls -l bar -rwsr-sr-x 1 user1 user 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:14 1996 Script started on Tue Jul 9 03:51:24 1996 $ whoami user2 $ cd /tmp $ mv ~user1/foo/bar . mv: ./bar: set owner/group: Operation not permitted mv: ./bar: set mode: Operation not permitted $ ls -l bar -rwsr-xr-x 1 user2 wheel 0 Jul 9 03:51 bar $ exit Script done on Tue Jul 9 03:51:39 1996 Since mv cannot preserve the uid, it SHOULD NOT preserve the setuid bit. I sent a problem report for this one. I unfortunately removed all the base sources from my machine since 2.1.5-RELEASE should be out soon. -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited >commercial< email is subject to a $100 proof-reading fee.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?873f31ai87.fsf>