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