Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site suadb.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!enea!suadb!anders From: anders@suadb.UUCP (Anders Bj|rnerstedt) Newsgroups: net.bugs.uucp Subject: Re: Read permission on /etc/phones Message-ID: <146@suadb.UUCP> Date: Fri, 5-Jul-85 12:14:03 EDT Article-I.D.: suadb.146 Posted: Fri Jul 5 12:14:03 1985 Date-Received: Sat, 13-Jul-85 11:02:07 EDT References: <472@qantel.UUCP> <170@motel6.UUCP> <>Reply-To: anders@suadb.UUCP (Anders Bj|rnerstedt) Organization: SU ADB, Sweden Lines: 43 In article pilotti@telesoft.UUCP (Keith Pilotti @shine) writes: > > However, with the 4.2BSD version of `tip', this causes the LCK files to > be left around after `tip' exits, preventing use of the port until > manual intervention by a "privileged user". > > `tip' creates the LCK file while SUID, and no longer has write > permission in /usr/spool/uucp once it changes the UID. The LCK > file therefore remains. > > For binary sites the only "solution" seems to be to leave this > directory writable. Yuck. You could circumvent the problem by writing a script (called say newtip) like: ---------------- #!/bin/sh #Newtip releases the lock file after tip terminates. if /usr/bin/tip $* then /usr/lib/uucp/lockrelease $* fi -------------- Where lockrelease is a simple program which suid's to root (or uucp) and removes the appropriate lockfile. We have a solution like this for using kermit over uucp lines while observing the locking conventions of uucp. This uses two small programs, both "lockrelease" and a "lockset". --------------------- Anders Bj|rnerstedt Department of Information Processing & Computer Science University of Stockholm S-106 91 Stockholm Sweden UUCP: {seismo,decvax,philabs}!{mcvax,ukc,unido}!enea!suadb!anders