Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles; site smu.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!inuxc!pur-ee!uiucdcs!smu!pedz
From: pedz@smu.UUCP
Newsgroups: net.unix
Subject: Tip problem - (nf)
Message-ID: <18500014@smu.UUCP>
Date: Tue, 24-Jul-84 00:19:00 EDT
Article-I.D.: smu.18500014
Posted: Tue Jul 24 00:19:00 1984
Date-Received: Fri, 13-Jul-84 23:47:42 EDT
Lines: 24
Nf-ID: #N:smu:18500014:000:1094
Nf-From: smu!pedz    Jul 10 23:19:00 1984

#N:smu:18500014:000:1094
smu!pedz    Jul 10 23:19:00 1984

I have a small question to ask about tip and uucp.  With our uucp, the
/usr/spool/uucp directory is suppose to be writeable only by the owner
which is uucp.  uucp sets the suid bit and is thus able to write into
the directory.  In particular, the lock files.  Tip tries to simulate
this by also setting the suid bit (and is owned by uucp) and is able
to create a lock file.  The problem is that tip then "drops" the uucp
status by setting the uid equal to the real uid.  This must be done
both from the standpoint of convenience and security.  The problem
is when tip finishes, it no longer has a uid of uucp and therefor
can not remove the lock file.

I can think of several ways to get around this problem.  One is to
move the lock files into a different directory.  The option of making
the /usr/spool/uucp writable by all is not a wise choice since any
person can destroy everything in that directory (which happened just
recently).  Has this problem been solved before?  Is it possible to
regain the status of running like uucp?

Thank you for any help you can give.
Perry
convex!smu!pedz