Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site cwruecmp.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!talcott!panda!genrad!decvax!cwruecmp!rob From: rob@cwruecmp.UUCP (rob robertson) Newsgroups: net.micro.att Subject: Re: S-bit set on UnixPC mv Message-ID: <1285@cwruecmp.UUCP> Date: Thu, 1-Aug-85 10:18:33 EDT Article-I.D.: cwruecmp.1285 Posted: Thu Aug 1 10:18:33 1985 Date-Received: Sat, 3-Aug-85 05:25:44 EDT References: <1284@cwruecmp.UUCP> <2511@sun.uucp> Organization: CWRU Dept. Computer Eng., Cleveland, OH Lines: 71 gwyn@brl-trg.ARPA (Doug Gwyn): >> A friend of mine noticed this, but the way at&t ships the Unix Pc software, >> the set uid bit on /bin/mv is set, and it is owned by root. >> >> With this, all a user need do is copy the passwd file to their own directory >> edit, and remove the passwd field, and then mv it back and then su to root. > >Foo! If this is the version of "mv" that I suspect it is (pre-mvdir), >the above scenario is entirely wrong. "mv" is set-UID so that it can >move directories (done by relinking, which requires root privilege). >Just because a program is set-UID root does not mean that it is stupid. fooey to you too, because the way it is on other systems doesn't mean it's the same on the Unix Pc. Unix ain't Unix.... See the following flame. guy@sun.UUCP(Guy Harris): >> A friend of mine noticed this, but the way at&t ships the Unix Pc software, >> the set uid bit on /bin/mv is set, and it is owned by root. > >I got news for you guys; "/bin/mv" is set-UID root on V7, System III, >4.1BSD, and System V Release 1. This is necessary because, except on 4.2BSD >where you can use the non-privileged "rename" system call, you must rename >directories by doing a "link" of the new name to the old name and an >"unlink" of the old name, and "link"s to and "unlink"s of directories are >privileged operations. S5R2 has a separate set-UID program to do moving of >directories. "mv" in all the non-4.2BSD/non-S5R2 systems gives up its >set-UID privileges as soon as it figures out that it's not moving a >directory; if it *is* moving a directory, it does all the requisite >permissions checking itself. I got news for you Guy: The current O/S of the Unix PC, you know the one mentioned in the header line is SYSTEMV 2.0. Try uname -a on your nearest Upc. >I don't know how much of the System V in the 7300's UNIX is S5R2 (where they >have a separate-UID program to move directories), but it may not have the >S5R2 "mv". I don't know either but one thing is true: with our version of /bin/mv I as an ordinary user can mv ANYTHING ANYWHERE I want it. For you non- believers try moving passwd to you directory then have everyone log out. >> With this, all a user need do is copy the passwd file to their own directory >> edit, and remove the passwd field, and then mv it back and then su to root. > >If it's the S5R1 "mv", you can *try* to "mv" the passwd file back - but >you'll fail. One question: Do you think I wrote this without trying it out? IT WORKS. >> To remove this "feature" just chmod -s /bin/mv and it will be taken care of. > >And (if it's the S5R1 "mv") discover that you can't rename directories any >more. And users will never pester the system manager for mounting disks again, they'll be able to do it themselves. I apologize to Guy if I'm a little perturbed, but evidently he doesn't have access to a Unix pc which my letter was about, not diffs in S5R1, BSD, S5R2 or V7. It was about what I could do on a Unix Pc with no privileges except login. If you have tried this on a Unix Pc, with the unmodified software and it doen't work then post articles And send me letters making me look like a fool. william robertson usenet: decvax!cwruecmp!rob 1615 hazel arpa: rob.case@csnet-relay cleveland, ohio 44106 csnet, bitnet: rob@case (216) 791-0922