Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/unix/volume22/auth/part01/dir.doc

Text File | 1990-04-29 | 4KB | 68 lines

The authentication directory, AUTHDIR/tcp, contains several different
types of files.

It is assumed that long ints representing Internet addresses take at
most ten digits, short ints representing TCP port numbers take at most
five digits, and ints representing process ids take at most five digits.

Files of the form I.L.R, where I, L, and R are integers, are username
files. There is one username file per auth connection to/from this host,
two for a local connection. I is the Internet address of the host on the
other end of a TCP connection, expressed as a single long int; L and R
are the connection's local and remote TCP ports respectively. The file
contains just the name of the user, up to eight characters long.

Files of the form ps.C.P, where C and P are integers, are attachport
process files. There is one process file for each connection served by
an attachport on this host. C and P are the process ids of the child
(server for a particular connection) and parent (attachport) processes
respectively. The file contains the name of a username file; in effect,
it points to the username file, so that the attachport can easily keep
track of each of its children.

Files of the form lock.L, where L is an integer, are lock files. L is
a local TCP port number. At any time there will be at most one auth
program handling connections to/from port L. When authtcp or attachport
starts, it opens the lock file with O_EXCL and writes its pid into it.
If that fails, it reads the lock file, checks that the process exists,
and gives an appropriate error. When it exits, it removes the lock file.

Lock files are also used to prevent race conditions during critical
moments between connecting or accepting a connection and creating the
appropriate username file. For attachport this is no big deal: it
selects for reading before accepting a connection, and from before the
accept() until the authentication entry is in place, it places an
exclusive flock() on the lock file. (This WILL NOT WORK if selecting
for reading performs an implicit accept. The race condition resulting
from such a bug could be extremely hard to detect; but don't say I
didn't warn you.) For authtcp, however, this is much more difficult:
an outgoing connect() may take practically forever, and there's no way
to precisely control the moment of connection as a select-accept can.
On the other hand, authtcp has all the local authentication information
it needs, before even beginning the connection. So it writes a colon,
the I.R remote information, a newline, and the username into the lock
file after its pid; it doesn't use a flock() except while updating the
lock file. authd will look in this file only if it fails to find a
username file; authentication requests rarely happen so quickly.
attachport also places extra information into the lock file, namely a
hyphen and the user name.

Observe that the duplicate authtcp information in the lock file gives
away the user name on the local side of a connection that has not yet
succeeded. Technically, this is not a violation of RFC 931, but it might
offend purists. Then again, it's symmetric with how the user name is
available for a moment after the connection is closed.

Latest addition to the lock file: If the first character is a ! then
attachport (or, in a later version, perhaps authtcp) has been killed by
the user during a critical moment. If you want a detailed explanation of
how and why this is used, ask auth's author.

If the auth package gets much more complicated, it may be worth imposing
a bit more structure on the authentication directory; hopefully all this
authentication information will be available from the kernel long before
that happens. The lock file system would have to be changed immediately
if auth were to support REUSEADDR; however, ftp seems to be the only
program that needs REUSEADDR, and PUFF is a much better file transfer
system.