hurf@batcomputer.tn.cornell.edu (Hurf Sheldon) (08/10/89)
I installed UWS2.1 (Ultrix3.1) on a vs3200 with some dhv11's
Our 'tip' lines reported 'all ports busy' unless run from
root. I checked and rechecked the permission settings on the
tty entries, on /usr/spool/uucp and on /usr/bin/tip. After
comparing the permission level on /usr/bin/tip on another
system (UWS2.0, vsII) I saw that the 2.0 had set /usr/bin/tip
permissions [correctly?] to 4711 but the 2.1 installation had
set /usr/bin/tip 755 (which appears normal but won't allow
creation of the lock file in /usr/spool/uucp)
I tried 'chown daemon /usr/bin/tip' and 'chmod 755 /usr/bin/tip'
in the hopes of not having to set root id but got the error
'can't open log file' .
I assume this is part of the obvious effort to plug security holes
in UWS2.1/Ultrix3.1 - just passing it on.
hurf
--
Hurf Sheldon Network: hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies Bitnet: hurf@CRNLION
369 Upson Hall, Cornell University, Ithaca, N.Y. 14853 ph:607 255 7267
I got a job in science; I bought a Porsche; Now, everyone takes me seriously.grr@cbmvax.UUCP (George Robbins) (08/10/89)
In article <8601@batcomputer.tn.cornell.edu> hurf@tcgould.tn.cornell.edu (Hurf Sheldon) writes: > > I installed UWS2.1 (Ultrix3.1) on a vs3200 with some dhv11's > Our 'tip' lines reported 'all ports busy' unless run from > root. I checked and rechecked the permission settings on the > tty entries, on /usr/spool/uucp and on /usr/bin/tip. After > comparing the permission level on /usr/bin/tip on another > system (UWS2.0, vsII) I saw that the 2.0 had set /usr/bin/tip > permissions [correctly?] to 4711 but the 2.1 installation had > set /usr/bin/tip 755 (which appears normal but won't allow > creation of the lock file in /usr/spool/uucp) It's... -rws--x--x 2 uucp daemon 92160 Oct 19 1988 /usr/bin/tip ...after the regular VAX 3.0 plus 3.1 installtion. > > I assume this is part of the obvious effort to plug security holes > in UWS2.1/Ultrix3.1 - just passing it on. I'll reserve judgement about right/wrong, but having it suid uucp opens the possibility more for nuisance security holes as compared to suid root. The alternative would be to have the uucp spool directory writable by anyone, with the "sticky bit" set so that only the creators of files can delete them. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)