J.Purchase@cs.ucl.ac.uk (Jan Purchase) (06/11/91)
Hello, I am experiencing some problems with /usr/bin/cu, and I'd be very grateful for any help. Firstly, I have been advised that it is good practice to prevent the uucp spool directory from being world writable. So I made it mode 775: drwxrwxr-x 3 uucp uucp 512 Jun 10 18:25 /usr/spool/uucp (A/UX 2.0.1 standard is mode 777). Now however, when disconnecting from a cu session (as a non privileged user), I get the message: Can't unlink lock-file The lock file, /usr/spool/uucp/LCK..*, is owned by root with mode 400. It was created by cu (which runs setuid root), so why can't it be unlinked by cu? Oddly, the problem does not occur if I run cu as root (or uucp). Equally oddly, the lock file does *not* stop cu from opening other sessions on the same device! It does, however stop kermit, which is very inconvenient. A second and (I think) unrelated problem concerns the way cu works when given a system name as an argument. cu does not appear to follow the instructions for logging on to a uucp neighbour as listed in /usr/lib/uucp/L.sys - it doesn't even attempt to (modem SD and RD lights do not flicker). Yet, uucico will obey the commands (indicating that the L.sys file itself is not flawed). Any Ideas? Cheers Jan.
urlichs@smurf.sub.org (Matthias Urlichs) (06/12/91)
In comp.unix.aux, article <1599@ucl-cs.uucp>,
J.Purchase@cs.ucl.ac.uk (Jan Purchase) writes:
<
< Firstly, I have been advised that it is good practice to prevent the
< uucp spool directory from being world writable. So I made it mode 775:
< drwxrwxr-x 3 uucp uucp 512 Jun 10 18:25 /usr/spool/uucp
< (A/UX 2.0.1 standard is mode 777). Now however, when disconnecting
< from a cu session (as a non privileged user), I get the message:
< Can't unlink lock-file
cu wisely revverts to the privileges of the real user after creating that
lock file. This is not a problem.
< The lock file, /usr/spool/uucp/LCK..*, is owned by root with mode 400.
< It was created by cu (which runs setuid root), so why can't it be
< unlinked by cu? Oddly, the problem does not occur if I run cu as root
< (or uucp). Equally oddly, the lock file does *not* stop cu from
< opening other sessions on the same device! It does, however stop
< kermit, which is very inconvenient.
<
The lock file contains the process ID (as a longint -- that's why it's four
bytes big). If the process in question doesn't exist, the lock file is
removed. This method is not 100% failsafe because process IDs get reused
after a while.
It would be much better if A/UX used a more modern version of UUCP,
preferably one which uses /usr/spool/lock or something like that -- the
directory name should be of the same length so that older programs can be
binary-patched if necessary. That way, the lock directory can be made mode
0777 without compromising anything.
Another problem with the stock A/UX Kermit is that it can't talk at 19200 baud.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/