Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!ddl
From: ddl@harvard.ARPA (Dan Lanciani)
Newsgroups: net.bugs.uucp
Subject: Re: Read permission on /etc/phones
Message-ID: <249@harvard.ARPA>
Date: Sat, 13-Jul-85 00:56:07 EDT
Article-I.D.: harvard.249
Posted: Sat Jul 13 00:56:07 1985
Date-Received: Mon, 15-Jul-85 00:46:08 EDT
References: <472@qantel.UUCP> <170@motel6.UUCP> <> <154@telesoft.UUCP> <696@lsuc.UUCP> <697@lsuc.UUCP> <1953@ukma.UUCP>
Organization: Aiken Computation Laboratory, Harvard
Lines: 40

> In article <697@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:
> 
> How does this solve anything?   I don't see where this removes the 
> lock file.
> 
> 1)	cleanLCK isn't called explicitly, only on a signal, which
> 	won't happen.
> 2)	cleanLCK *cannot* know which lock file to delete.
> 
> 
> Answer me one question, why are we discussing tip problems in net.bugs.uucp?
> -- 
> --- David Herron
> --- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> 
> ---	   or david%ukma.uucp@anl-mcs.arpa
> ---        Or even anlams!ukma!david@ucbvax.arpa
> --- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
> ---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david
> 
> 	"It's *Super*User* to the rescue!"

	Although I never tried to fix tip, I encountered the same problem
with cu on 2.9.  The solution I found was to retain the effective uid
by swapping uid's (setreuid(geteuid(), getuid())) after creat'ing the
lockfile.  With the effective uid set back to the caller's real uid,
file accesses work correctly and the only pitfalls are shell escapes
and such which much be prefaced with a setuid(geteuid()).  When it
comes time to remove the lockfile (or access /etc/phones) just swap
uid's again.
	Of course, not everyone has a setreuid call, but it does seem
to solve the common problem of setuid programs which must access user files.
(The access system call really isn't much good for any user except root...)
Also, while cu is simple enough that I could satisfy myself that this
approach didn't introduce any security holes, tip may be more complicated.
	Almost forgot:  If you do this to cu, be sure to swap uid's
again before trying to kill the reader process or else have it run as
your real uid.

						Dan Lanciani
						ddl@harvard