Date: 10 Jul 1996 23:38:48 -0500 From: Zach Heilig <zach@blizzard.gaffaneys.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: "M.R.Murphy" <mrm@MARMOT.Mole.ORG>, bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1375: Extraneous warning from mv(1) Message-ID: <87raqjjtev.fsf@freebsd.gaffaneys.com> In-Reply-To: Garrett Wollman's message of Wed, 10 Jul 1996 11:15:05 -0400 References: <199607100538.WAA29432@meerkat.mole.org> <9607101515.AA15173@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman <wollman@lcs.mit.edu> writes: > I think I have a better proposal, which is essentially the same as > Bruce's: > 1) If the gid of the directory is in cr_groups[], then use it. > 2) Otherwise, use cr_groups[0]. This is more or less what I was trying to say in my very first message, but perhaps I flubbed it up :-). I think the current behavior should be an option, perhaps by requiring the setgid bit to be on the parent directory. I don't see an obvious need for this, except perhaps for mail spool directories. It would not be required for workgroups, since (presumably) everyone working on files in the project directory are also in the correct group, so the right thing would happen anyway. There are still some issues having to do with what mv(1) and related utilities do with the group read, write, and execute/search bit; the setuid bit; and the setgid bit. The other read, write, and execute/search bits don't matter as much, since they don't try to restrict who can access the file (and if they were on, there is really no reason to turn them off). We need to come up with a consistant (and BSD-like) behavior for what exactly should be done when some combination of those bits are set. The current mv(1) handles the case of setuid/setgid bits very badly. I read the man page for what cp(1) is supposed to do regarding permissions (I didn't verify that works as advertised), and I don't think its behavior as documented covers all the bases very well when applied to mv(1). mv(1) really really wants to preserve the precise mode and ownership flags, but cp(1) merely gives it a good effort, if you tell it to. But since it is simply copying, cp(1) doesn't complain if preserving the flags is impossible. These issues are also valid for archival programs like tar, cpio, pax, etc.. since they are always "moving" files across "filesystems". First, regarding the filesystem flags, I think we all can agree that some of the flags should be preserved when moving across filesystems. The question is which ones? Obviously uchg and schg files need to be left completely alone, but what about the dump flag? I'm not completely sure what that means (the man page helpfully says that if the nodump flag is set, the file should never be dumped. Dumped meaning never discarded, or never copied, prevent the use of dd(1), or ??). Next, about the file-mode mask. When should the other read, write, execute/search; group read, write, execute/search; setgid; and setuid bits be ok to preserve, and when should some or all of them be dropped? This will probably have to depend on the umask setting when deciding if to keep the write, read or execute bits when either the owner, gid, or both have to change. Consider these situations: 1) There is a file with the mode '-rwxrwsr-x', and you need to move it to a public bin directory on a different filesystem. You do not own the file, but one of your gids is the same as the file's gid. You have write permissions to the directory you are moving to (perhaps the bits are 'drwxrwxr-x'). After mv(1) finishes, what permissions should the file have? I say the bits should be '-rwxrwsr-x' with you as the new owner, but the file still has the original gid. 2) The original file has the mode bits '-rwsrwsr-x'. Obviously, if you are not the owner, the setuid and probably the setgid bit should be dropped. Should mv(1) print out a message saying it dropped them? I think so. Should the move succeed at all? The answer is debatable, but I'm beginning to think it should not, even if you could simulate the move with appropriate calls to rm(1), cp(1), chmod(1), and chgrp(1). 3) You own a file with mode '-rwsr-x---', but for some reason, none of your gids match the file's gid (you might have been kicked out of that group, or it is from an archive made on a different system). You would no longer want logins with a gid that matches the files gid to be able to execute that file (since it is setuid), but you want to continue using it yourself. You move the file into your personal bin directory. Since none of your gids match the file's gid, the file's new gid changes to the gid on your bin directory (whew!). This would give a different group execute permissions for that file if the mode bits stayed the same. This is probably not acceptable, so should the permissions after the move be '-rwxr-x---', or '-rws------'? I don't know, but the bits should not be '-rwsr-x---'. 4) Same situation as #3, but the original file's permissions are '-rwsr-xr-x'. In this case, I think the permissions should be unchanged after the move (You would not be giving a different set of people access). There are many more examples that should be looked into to make sure the archive and file utilities do the right thing in preserving the various bits and ownerships. The operations should be atomic, in case the file contains sensitive information that only certain people should have access to. By that, I mean files should be created with the correct permissions and ownerships already attached before the copy starts. If the gid cannot be preserved, and none of the 'other' bits are on, the group bits should be forced off as well. This means that mv(1) and the various archive programs should check to see if the gid (and perhaps the uid) can be preserved before creating the file, and calculate the proper mode bits to pass to open(2), creat(2), or mkdir(2). This way, the file would always have the access bits set properly, and there would be no race condition where "unauthorized" people could access the file. I have much more to say on this subject, but I would like some feedback first ;-) -- Zach Heilig (zach@blizzard.gaffaneys.com) Support bacteria -- it's the only culture some people have! ALL unsolicited commercial email is unwelcome. My policy is avoid dealing with companies that send out such mailings.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87raqjjtev.fsf>