brad@bradley.UUCP (01/10/88)
chances are the lock files are made with euid == uucp then later on tip seteuid(getuid()); In this case if the directory /usr/spool/uucp is public writeable, then it can, if not it can't remove it.
jthomp@tsunami.UUCP (01/13/88)
>/* Written 10:43 pm Jan 8, 1988 by bsu-cs.Sun.COM!dhesi in tsunami:comp.unix.wizards */ >In article <525@srs.UUCP> matt@srs.UUCP (Matt Goheen) writes: >>> For some reason, the "tip" program here refuses to remove the device >>> lock files when it exits. > >Some of the UUCP family of utilities, at exit time, derive the name of >the lock file to use by finding the name of the terminal in use knowing >only the file descriptor. (I conclude this from their behavior, not >from looking at the source code). If two or more links exist to the >terminal device, the utility may hit upon the wrong name and attempt to >remove the wrong lock file. So check to see if any of your UUCP >devices is known by more than one name. >-- >Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi >/* End of text from tsunami:comp.unix.wizards */ Foo. I don't think this is the case at all. Rather consider that the programme, (tip in this case) is usually installed 'set-uid uucp', (or daemon, or some clap..). This is so that it can open the 'call-devices', logfiles, etc. when it needs to. Consider also that it would be bad to have users out there gaining all the privilages of 'being' uucp while executing 'tip'. So, somewhere after the 'device' is successfully opened, tip does the .eq. of setuid(getuid()) Thusly, 'undoing' any privs that Joe Unix might gain. The problem comes at 'exit' time. 'tip' has created a 'LCK..foo' file in /usr/spool/uucp, (in accordance with the 'uucp' locking mechanism.) the programme doesn't 'have' the necessary permissions (anymore) to unlink(2) the file in question. Solution (if you have 4.{2,3}) A programme can always get its 'effective' uid back, so the following should work.. After opening everything you need to (logfiles, ACU's....) do: gid = getgid(); /* save */ egid = getegid(); uid = getuid(); euid = geteuid(); setregid(egid, gid); /* undo the poor sod's perms */ setreuid(euid, uid); And before any kind of 'exit', if(uid != getuid()) { /* if we don't alreay have those privs */ setreuid(uid,euid); /* get 'em back */ setregid(gid,egid); } unlink(foo); /* the lock file */ [...] exit(0); --jim Jim Thompson Convex Computer Corporation 701 N. Plano Road Richardson, Texas 75081 (214) 952-0200 {uiucdcs,ihnp4,sun,allegra,harvard}!convex!jthomp Spelling errors included for humility.
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (01/16/88)
In article <523@srs.UUCP> matt@srs.UUCP (Matt Goheen) writes: > For some reason, the "tip" program here refuses to remove the device > lock files when it exits. I just had occasion to look at tip in great detail. (I added the acucntrl dialin-dialout code to it, to allow all modems to be both dialins and dialouts.) What you observed is one of several BSD4.3 tip bugs concerning setuid/setgid confusion. Tip gets confused about swapping the real and effective uids/gids in the appropriate places. In your case, tip does infact try to remove the lock file with the wrong uid (uid=<users-real-uid>) if you break a tip connection with "~." (however, tip gets it right in the case where you logout of the remote host, and the remote host drops the carrier.) Tip also reads your private $REMOTE/$PHONES file with uid=uucp gid=daemon (or whatever you set the setuid/setgid to). This is a bug that hits you if you have a mode 600 phones file. What did I do to fix these bugs? Hell, I'm not paranoid. I made the /usr/spool/uucp/LCK/ mode 777. (Playing swap the uids in tip just got too confusing too quickly.) -wolfgang --- Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) Independent Consultant UUCP: {mit-eddie!mgm.mit.edu,mirror!mit-mgm}!wolfgang VOICE: Hey_Wolfgang!_(617)_267-4365