muller@sdccsu3.UUCP (07/15/84)
I got around the problem by changing tip and cu to be both setuid and
setgid to uucp (or whatever group your uucp is in). I changed /usr/spool/uucp
to be group writable (mode 775) and made the following changes. Although this
is not completely bulletproof it is a bit better than having a world writeable
/usr/spool/uucp.
Keith Muller
UCSD Computer Center
RCS file: RCS/Makefile,v
retrieving revision 1.1
diff -r1.1 Makefile
71c71
< install -m 4711 -o ${OWNER} -g ${GROUP} tip ${DESTDIR}/usr/bin/tip
---
> install -m 6711 -o ${OWNER} -g ${GROUP} tip ${DESTDIR}/usr/bin/tip
-------------------------------
RCS file: RCS/cu.c,v
retrieving revision 1.1
diff -r1.1 cu.c
0a1
> /* $Header: cu.c,v 1.2 84/02/22 14:04:47 muller Exp $ */
4a6,12
> /* $Log: cu.c,v $
> * Revision 1.2 84/02/22 14:04:47 muller
> * removed a line of code that reset the effective group id back
> * to the real users group id. This is the same change as in tip.c to
> * allow removal the lockfile from /usr/spool/uucp.
> * */
>
85d92
< setgid(getgid());
---------------------------
RCS file: RCS/tip.c,v
retrieving revision 1.1
diff -r1.1 tip.c
0a1
> /* $Header: tip.c,v 1.2 84/02/15 17:05:07 muller Exp $ */
4a6,12
> /* $Log: tip.c,v $
> * Revision 1.2 84/02/15 17:05:07 muller
> * removed the code that reset the effective group id. This caused the
> * lockfile removal to fail since the uucp directory is no longer
> * writeable by others.
> * */
>
103d110
< setgid(getgid());
--------------------------
RCS file: RCS/uucplock.c,v
retrieving revision 1.1
diff -r1.1 uucplock.c
7c7
< #define NAMESIZE 15
---
> #define NAMESIZE 40
171a172
> fchmod(fd, 0444);pedz@smu.UUCP (07/24/84)
#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