Hurd Traffic #108 For 17 Sep 2001

The real solution is to use DT_RUNPATH (not RPATH!) when linking the executable, but this will have to wait for the next major binutils version. The reason it works for you is thta you have LD_LIBRARY_PATH set, I would guess (like in /etc/profile)

The reason it doesn't work with xdm is that this program ignores the LD_LIBRARY_PATH env variable for security reasons. You can configure this, though. [] Somewhere in /etc/X11/xdm you can tell it to not ignore the value, or even set it to some fixed value.

I want to tackle the issue of support for translators as used in the Hurd by tar. This is important for installation tar files (/dev/ nodes), for example.

For the tar maintainer: The Hurd allows to attach programs to filesystem nodes, those programs service all filesystem accesses (inkl. stat()!). Such running servers are active translators, and mostly transparent to the user. We have GNU extensions in the C library to detect them, though (but we need _GNU_SOURCE).

The servers can be started transparently from passive translators which is a command line string stored in a block of the filesystem and associated with an inode. This command line string is used to start up the actuve translators.

It is those passive translators that should be stored and restored by tar on request.

Some properties of passive translators (aka translators from now on) are shared by symlinks. Both are stored as a string connected to an inode. Both can be dereferenced or not. In fact, symlinks are implemented as special translators in the most general case (for efficiency, filesystem servers can use native symlink support if they want). A symlink is by definition a "/hurd/symlink TARGET" translator. The program /hurd/symlink exists and is a translator that provides the expected functionality (of course, this program is not regularly used, and POSIX programs see the symlink as defined by POSIX).

Now to tar. Of course, reading and writing translators is a GNU extension. All calls necessary to do this are part of the C library, so it is easy to add the support (autoconf-wise). I expect that the archive management code is mostly the same between long symlinks and translators.

The default for symlinks is to store them, dereferencing is possible with -h (--dereference). For translators, I think the opposite should be true. Users expect translators to be transparent to normal applications. For example, mount points are also translators, and I expect tar to not store the mount point settings, but the data within.

The check for a translator should be done before any other check, to avoid starting up the server unnecessarily (any normal file i/o on the node, even a stat(), starts up the server). There is one complication. Symlinks, device files, fifos and similar are also implemented as translators. However, I'd expect that a symlink together with the --do-not-dereference-translators option will not store a /hurd/symlink translator, but a symlink. So, the translator handling code will recognize the couple of special translators and coerce them into archive entries compatible to traditional Unix systems.

I write all this to make sure the above is what everybody wants, and in the hope to get some pointers into the relevant parts of the tar code. Of course, if the tar people (Paul?) want to do the changes, I am happy to just assist with the Hurd specific parts and testing. The reason I am not just diving into the source is that the details of tar are quite complicated (format versioning etc), and I am sure that I would spent a lot of time just figuring out where to put the code.

There has been a lot of talk about extending 'ls' to display the Hurd's fourth rwx permission set. When someone eventually does that, (s)he could also add an option for showing passive translators. That would be more convenient than a separate 'showtrans' program, I think. The output could then also obey the '--quoting-style' option.

The tar format should be extended to support the following data for each file, in addition to what it stores already:

1. Passive translator:
   • Usage: Command line for a program that the parent filesystem starts when a process looks up the file.
   • Type: List of strings. The strings cannot contain null characters.
   • Frequency: Most files haven't got passive translators.
   • Format: The RPC interfaces and ext2fs (I don't know about ufs) keep the passive translator in argz format (see the glibc manual) so it could be easiest to use that format in the tar file too. The ext2fs format restricts the argz to the filesystem block length minus two bytes, but I don't think tar should inherit that limitation.
   • Default: When extracting a non-Hurd archive, don't set a translator except implicitly via mknod or symlink.
   • API: There is S_IPTRANS for mode_t, but I think that's a bit late since a stat already uses the translator. 'showtrans' gets a Mach port to the file with file_name_lookup, reads the passive-translator argz with file_get_translator, and closes the port with mach_port_deallocate. 'settrans' uses file_set_translator in a similar way.
2. Fourth rwx set:
   • Usage: Read, Write and Execute permissions for processes that don't have any UIDs at all. There is also a bit that says whether the fourth set is active. If it is not active, then the "other" set is used instead. Legacy programs that set permissions are expected to store 0 in the activity bit, which currently means "not active". Some later version of the Hurd may change 0 to mean "active", so that UIDless processes don't get any permissions by default (since the rwx bits are also 000).
   • Type: 3+1 bits.
   • Frequency: In principle, all files have these bits. However, they will often be all zero.
   • Format: If the bits are zero, I think they needn't be saved. The possible future inversion of the activity bit could corrupt permissions of old tar files. I think it is best to only design the format for now and not actually save nonzero values until we know for sure whether the bit will be inverted.
   • Default: Zero. If it's good enough for legacy programs, it's good enough for legacy archives.
   • API: These mode_t bits can be read with stat and changed with chmod. Constants: S_IUSEUNK, S_IUNKNOWN, S_IUNKSHIFT. See <bits/stat.h> for details.
3. Author ID:
   • Usage: Another UID. Doesn't affect any permissions. The owner or root can store any value here.
   • Type: uid_t, 32 bits.
   • Frequency: All files have an author ID, but it is normally the same as the owner UID.
   • Format: I suppose tar could store both the number and the name, like with UID and GID.
   • Default: When extracting a non-Hurd archive, don't set the author ID; let the file system choose the default. (FIXME: Is this reasonable if 'tar' then does a chown?)
   • API: To read the author ID, use stat and see st_author. To change it, get a Mach port to the file and call file_chauthor.