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