problems with cu

Matthias Urlichs urlichs at smurf.sub.org
Wed Jun 12 13:19:20 AEST 1991


In comp.unix.aux, article <1599 at ucl-cs.uucp>,
  J.Purchase at 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 at smurf.sub.org -- urlichs at smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/



More information about the Comp.unix.aux mailing list