Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!quintus!sun!pitstop!texsun!texsun.Central.Sun.COM!convex!tsunami!authorplaceholder
From: jthomp@tsunami.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Lingering LCK..cua0 files (tip)
Message-ID: <63500010@tsunami>
Date: 13 Jan 88 06:14:00 GMT
References: <523@srs.UUCP>
Lines: 76
Nf-ID: #R:srs.UUCP:-52300:tsunami:63500010:000:2434
Nf-From: tsunami.UUCP!jthomp    Jan 13 00:14:00 1988


>/* 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.