aeusemrs@csun.UUCP (Mike Stump) (01/20/87)
In article <807@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: >In article <1987Jan14.123035.20364@sq.uucp> ian@sq.UUCP (Ian F. Darwin) writes: >>In my humble opinion, the very *existence* of mvdir as separate >>from the normal mv command is a bug. > >I agree completely. [...] >Against this [System V] must be balanced: > 1) Above-mentioned bug (yes, bug) in mv > >Although I suspect the reasons are political and not technical, I wonder >if anyone at AT&T (or anyone else who thinks they know the real story) >could comment on why so much in S5 is missing and/or wrong. Gee, I though every one knew why they FIXED mv in System V. It is a security loophole, isn't it obvious? (:-)) That is why they ONLY allow root to run it in SVR2. Ok, now to get to the meat of the matter: given directories d[0-1]*, where d0 is the base, and files f[0-1]*, (e.g. d0/d1/f1*, d0/f0*), d0 is drwxrwx--- user1 grp1, d1 is drwxr-x--- user2 grp1, f1* is -rw-r----- user2 grp1, in System V R2, I (being user3 grp1) I canNOT get `rid' of f1* because I don't have write in d1, but, if there existed mvdir in mv, or mvdir in general, then I can mkdir d1new, selectively `cp d0/d1/* d0/d1new', and now for the tricky part, `mvdir d0/d1 /tmp/kill_it_for_me', and `mv d0/d1new d0/d1', put the files I WANT into d1, after all I am now owner of it, I did the `mkdir', and then restore all the modification and access times in d1, and to cap it all off, `chown original_owner d0/d1/*', and `chown original_owner d0/d1'. All nice and tidy like. And nobody would be the wiser. If I could not `mvdir', the original directory d0/d1 would have to be left in d0/.d1 or something forever, and eventually somebody would spot it, and say: `Gee, what is this?' Oh, one thing, I am not sure if the cron job (or whatever) runs in `root' but I would hope it would, and thus, it, of course could kill the mvdir'ed directory and recursively all the files in it for me. Gee, some people actually don't know that Unix is not very secure. I know, don't flame me, I am not overly naive, it is the problem with the person that set up the group write priv on d0 that screwed it all up, but this is only due to the fact that (properly) managing a Secure Unix is overly complex. I agree completely (I hope) that Unix (when managed properly) is very secure. I know this one little article is going to cause an avalanche of of articles, but I feel I can say nothing to stop them... -- Mike Stump, Cal State Univ, Northridge Comp Sci Department uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs
rcodi@yabbie.rmit.oz (Ian Donaldson) (01/23/87)
In article <512@csun.UUCP>, aeusemrs@csun.UUCP (Mike Stump) writes: > Gee, I though every one knew why they FIXED mv in System V. > It is a security loophole, isn't it obvious? (:-)) That is why > they ONLY allow root to run it in SVR2. > Ok, now to get to the meat of the matter: <long explanation of an example> > it > is the problem with the person that set up the group write > priv on d0 that screwed it all up Yes, but since it is a problem with some administrator screwing things up then why change the mv command? The problem would have surely disappeared by using chmod appropriately, no? Publicly or Group writeable directories are certainly asking for trouble in the wrong environment. If there is a better explanation of why mvdir was separated out from mv, I and probably many others are all ears. > I agree completely (I hope) that Unix (when > managed properly) is very secure. Surely, as good as the next system. Given the freedom that *can* be made available under UNIX in the appropriate environments that just *isn't* available on a lot of other O/S's, its certainly nice to have a choice in the matter. > I know this one little article is going to cause an avalanche > of of articles, but I feel I can say nothing to stop them... You're probably right. Ian D.
allbery@ncoast.UUCP (01/26/87)
As quoted from <402@yabbie.rmit.oz> by rcodi@yabbie.rmit.oz (Ian Donaldson): +--------------- | If there is a better explanation of why mvdir was separated out from mv, | I and probably many others are all ears. +--------------- I was under the impression that it was done for the same reason that rmdir isn't part of rm. Under System III, mv could only move a directory from one name to another if it stayed within the same parent directory. System V mv is more general; unfortunately, it now has to deal with `.' and `..'. Written correctly, mv/mvdir could be used like rm/rmdir by ordinary users. It is my hope that the separation of the two is a first step in doing this, the next step being the trapping of illegal situations like that done by rmdir and rm -r. ++Brandon -- ____ ______________ / \ / __ __ __ \ Brandon S. Allbery <backbone>!ncoast!allbery ___ | /__> / \ / \ aXcess Co., Consulting ncoast!allbery@Case.CSNET / \ | | `--, `--, 6615 Center St. #A1-105 (...@relay.CS.NET) | | \__/ \__/ \__/ Mentor, OH 44060-4101 \____/ \______________/ +1 216 781 6201
guy@gorodish.UUCP (01/29/87)
>I was under the impression that it was done for the same reason that rmdir >isn't part of rm. Nope. "rmdir" and "rm" are both unprivileged commands; "mvdir" is superuser only. The only reason I can see why S5 has all that extra "mvdir" and "mv_dir" baggage is that they *still* haven't implemented "rename" and didn't want to have "mv" be set-UID root. Once you've implemented "rename", any unprivileged program can move directories around to its heart's content and the system will make sure they don't snarl up the directory tree. It is *my* hope that they pick up "rename" (which is likely, since it's in POSIX) and nuke "mv_dir" and "mvdir" entirely. One could make the same argument about "rmdir"; now that there's a "rmdir" system call (even in S5, with the advent of S5R3), "rmdir" doesn't need to be privileged. I don't know why "rm" didn't just "exec" "rmdir" when it was told to remove a directory, back when there was no "rmdir" system call; since that was never done, people may not have bothered folding "rmdir" into "rm" once you didn't have to be privileged to remove directories.
levy@ttrdc.UUCP (02/01/87)
In article <12301@sun.uucp>, guy@gorodish.UUCP writes: >[Somebody writes:] >>I was under the impression that it was done for the same reason that rmdir >>isn't part of rm. > >Nope. "rmdir" and "rm" are both unprivileged commands... Careful: as of this time, for System V this is only true in Release 3. Earlier releases had no rmdir() syscall; the rmdir program was setuid root and checked for protections and that the directory was empty except for . and .. , then used unlink() to delete the victim directory entries for . and .. , then the entry in the parent directory itself. You did out point the SysVR3 restriction later in your posting, to be fair, but it could be misleading to a reader who only sees the first part of your posting, which looks like a categorical assertion that System V per se (the rubric of this newsgroup) needs no privileges for rmdir. $ uname -a ttrdc ttrdc 2.0v3 0915 3B-20S ^^^^^ (N.B.: Release 2.0 Version 3. Not Release 3.) $ ls -l /bin/rmdir -rwsr-xr-x 1 root sys 8480 Oct 16 1983 /bin/rmdir -- ------------------------------- Disclaimer: The views contained herein are | dan levy | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, allegra,ulysses,vax135}!ttrdc!levy