rosso@sco.COM (Ross Oliver) (11/16/88)
There have been a number of questions about UUCP locking under the new release of SCO XENIX. Here are a few useful comments from one of our engineers: SCO XENIX Release 2.3: HoneyDanBer UUCP Device Locking ====================================================== SCO XENIX Release 2.3 replaces the old UUCP package with the HoneyDanBer implementation, with all the additional features that provides, and many of the features from its earlier UUCP - for example, speed ranges, and specialist dialer programs in addition to the HoneyDanBer dialer scripts. One area in which this differs slightly from the old UUCP, is in the conventions for locking a device. The communications programs cu, ct, uucico, and the rest of UUCP supplied with SCO XENIX 2.3, all follow the new convention. But users who have other programs which participate in the UUCP device locking scheme will need to adapt those programs to the new convention. In the old convention device tty1a, for example, was locked by creating a file named LCK..tty1a in /usr/spool/uucp. This file contained the pid of the locking process in binary. The lock file had to be touched from time to time: otherwise, after 24 hours an untouched lock would be regarded as expired, and so removed by another program needing to lock the device. Much the same is done by the new UUCP, but there are significant differences. Again, tty1a is locked by /usr/spool/uucp/LCK..tty1a, but now the pid it contains is in decimal ASCII: 10 characters including leading spaces, and followed by a newline. Note that if a lock file is shorter than 11 bytes (or if it is unreadable), HoneyDanBer UUCP considers the lock invalid, and will replace it by its own lock - which implies that HoneyDanBer UUCP is liable to disregard device locks set by programs following the old locking convention. Locks no longer expire after a fixed time, and do not have to be touched. Instead, if HoneyDanBer UUCP finds an existing lock file, it retrieves the pid from the file and tests whether that process is still active by kill(pid, 0). If this fails for any reason other than EPERM, the lock is considered expired, and therefore removed. Another difference is peculiar to the SCO XENIX implementation of HoneyDanBer UUCP. Because XENIX devices tty1A and tty1a represent the same line, with and without modem control, it is important that locking one should lock both. Therefore the final character of the device name is always (if alphabetic) lower-cased when constructing the lock file name, so tty1A is also locked by /usr/spool/uucp/LCK..tty1a. If you are writing or modifying a program to participate in the SCO XENIX 2.3 UUCP device locking scheme, proceed as follows. First create a temporary file e.g. /usr/spool/uucp/LTMP.pid, write the pid into this file - fprintf(fp, "%10d\n", getpid()), close and chmod 0444 (read-only protects against simpler programs which directly creat the lock file). Then try to link this to the lock file name (final character lower-cased). If the link fails, read the pid from the existing lock file (if open or read fails, the lock is not valid) and try kill(pid, 0) - if that call fails (with errno other than EPERM) then the process which created the lock has died without removing the lock file, so just unlink it and retry linking the temporary file. Finally, remember to unlink the temporary file; and when the program has finished with the device, unlink the lock file. Note: in 2.3, /usr/spool/uucp is writable by all users, so any program can make a lock file there. However, for security reasons this may change in future releases. Since UUCP lines are owned by uucp, a program which is to share lines with UUCP should be run setuid uucp; if it does not share lines with UUCP, then it need not use /usr/spool/uucp for its locks. Note also that if the program draws on UUCP's list of devices in /usr/lib/uucp, this file was named "L-devices" before but "Devices" in HoneyDanBer UUCP, with a slightly different format (dialer as fifth field of an entry).
erik@mpx2.UUCP (Erik Murrey) (11/18/88)
[ regarding the fact that the locks are stored in /usr/spool/uucp for
SCO's 2.3.1 HDB-uucp ]
I really wish SCO hadn't done this. It is a simple define in
uucp.h or param.h that lets the lock files reside in /usr/spool/locks.
This way, only /usr/spool/locks needs to be 0777, and only the
uucp programs need to be setuid. Kermit, etc, can run normally,
and set the locks in /usr/spool/locks.
This is how the stock 3b2 BNU system did it.
--
Erik Murrey /| // /~~~~/ | /
MPX Data Systems, Inc. / | / / /____/ |/
erik@mpx2.UUCP / / / / /| Data Systems, Inc.
{spl1,vu-vlsi,bpa}!mpx1!erik / / / / |====================