You've come to this page because you've asked a question similar to the following:
What are the various daemons, servers, and translators on The Hurd?
This is the Frequently Given Answer to such questions.
This is an incomplete list of all of the daemons, servers, and translators on The Hurd. Further information is always welcome.
/hurd/null
/hurd/null is a translator.
It is conventionally a passive translator on /dev/null and /dev/full.
In the latter case, it is invoked with the --full command-line option.
In normal operation, without that option, it serves up a "null" file, which discards all writes and returns EOF on all reads.
With the option, it serves up a "full" file, which returns ENOSPC on all writes and returns zeroes on all reads.
/hurd/magic
/hurd/magic is a translator.
It returns special magic values to clients that are performing directory lookups that causes the POSIX runtime library in those clients to perform special actions internally.
It does this because there are some common device file semantics that depend from knowing the state of the client process, that a translator has no access to.
So several magic values are included in the RPC I/O protocol that instruct the client to perform lookups internally.
/hurd/magic can be invoked with the tty command-line argument.
In this configuration, it returns to clients the magic value that instructs them to access their controlling TTY.
It is with this option that /hurd/magic is conventionally a passive translator on /dev/tty.
/hurd/magic can be invoked with the --directory fd command-line option and option argument.
In this configuration, it returns to clients the magic value that instructs them to access their own file descriptors.
It is with this option that /hurd/magic is conventionally a passive translator on /dev/fd.
Note that because the translator has no access to the client's internal state, it is not possible for the translator to provide a list of the client's currently open file descriptors.
This is why ls of /dev/fd/ does not work as one would expect it to.
/hurd/tmpfs
/hurd/tmpfs is a translator.
It serves up a filesystem that has no backing storage other than the machine's volatile RAM.
(More precisely, the backing storage is the virtual memory of the translator process itself.)
It is conventionally a passive translator on /dev/shm.
The nodes below this root are used by the POSIX runtime library to implement the shm_open() and shm_unlink() system calls.
The POSIX permission flags of the root directory of the filesystem may be controlled with the --mode command-line option, which takes the octal representation of the permission flags as an option argument.
The first command-line argument to the translator specifies how much memory the translator process will allocate to the filesystem. It is expressed as a decimal percentage figure of the machine's total physical RAM.
/hurd/console
/hurd/console is a translator.
It serves up a directory containing virtual console devices.
It is conventionally a passive translator on /dev/vcs, serving up subdirectories named /dev/vcs/1, /dev/vcs/2, and so forth, under which the actual files containing the console data are served up as /dev/vcs/1/console and so forth.
Two things employ the files and directories served up by /hurd/console.
The back-end of the /hurd/term translator uses them as the console cell arrays and sources of character input.
And the /bin/console command uses them as console cell arrays to display and sinks for input device events.
/hurd/term
/hurd/term is a translator.
It serves up a single file that has all of the POSIX semantics of a terminal device.
It is conventionally a passive translator on /dev/console, /dev/com[0-9], /dev/tty[1-9], /dev/tty[1-9][0-9], /dev/tty[pqrstuvwxyzPQRS]?, and /dev/pty[pqrstuvwxyzPQRS]?.
It can function as a translator for all of these different things because it contains a range of back-ends, which may be selected via command-line options and arguments.
The first command-line argument to /hurd/term is the name of the node on which it has been set as a translator.
The second and subsequent arguments control which back-end is employed:
pty-master nodename/hurd/term uses the ptyio back-end and serves up the master side of a PTY device, connected to the slave side at nodename.pty-slave nodename/hurd/term uses the ptyio back-end and serves up the slave side of a PTY device, connected to the master side at nodename.device devname/hurd/term uses the devio back-end and serves up the Mach device devname (which is usually console or com[0-9]) as a terminal device.hurdio nodename/hurd/term uses the hurdio back-end and serves up the Hurd device nodename as a terminal device.
Conventionally, nodename will be /dev/vcs/1/console or similar, served up by the /hurd/console translator./hurd/storeio
/hurd/storeio is a translator.
It serves up a single file that provides access to a "store" via the normal file I/O protocol.
Its command-line arguments are a list of the "stores" to serve up.
It handles blocking and deblocking of I/O transactions, and employs an internal block cache on top of the raw "store" access.
It is conventionally a passive translator on /dev/fd*, /dev/mt*, and /dev/{hd,sd,rd,cd}*, with the "stores" specified being the corresponding Mach kernel devices (of the same names).
With no other command-line options, the specified "stores" are simply served up concatenated.
With the --layer command-line option they are instead layered, for redundancy.
With the --interleave=N command-line option they are interleaved in runs of N blocks.
Other command-line options are --readonly and --writable, which control read/write access, --rdev=N which controls the major and minor device numbers of the node that the translator serves up, and --store-type=T which explicitly forces the types of the "stores".
/hurd/hostmux
/hurd/hostmux is a translator.
It serves up a single node which is a directory of nodes served up by other translators, that it instantiates upon demand with parameters derived from the node names.
The node names are checked against the DNS before the sub-translators are instantiated.
Conventionally, those translators are /hurd/ftpfs or similar, because the intent of /hurd/hostmux is to provide a way for automatic specification of the server, targetted by an FTP or an HTTP client, via the node name in the filesystem.
e.g. If /hurd/hostmux is a translator on /tmp/ftp, it will arrange that /tmp/ftp/example.com./ be served up by a /hurd/ftpfs translator that is configured to use example.com. as the FTP server.
/hurd/password
/hurd/password is a translator that provides authorization services.
It serves up a single node and is conventionally a passive translator on /servers/password.
It does not serve up the file I/O protocol, returning EOPNOTSUPP for all file protocol operations.
Rather, it serves up the password protocol on its node.
This protocol supports two remote procedure calls, password_check_user() and password_check_group(), that check (respectively) user+password and group+password pairs against the databases in /etc/shadow and /etc/gshadow.
Upon successful password verification, it returns to its client a send port right for the /hurd/auth server.
/hurd/exec
/hurd/exec is a server that provides process execution services.
Given a process image file and a (new) Mach task, it will update the process database (maintained by the /hurd/proc server) with the new program environment, arguments, and privileges; load the process image into the address space of the task; and commence its execution, passing to it send port rights for the root directory server, the current directory server, the /hurd/auth server, and the /hurd/proc server.
If the process image file is a script file, signified by a #! marker, it will load the image of the specified script interpreter program into the process' address space.
/hurd/proc
/hurd/proc is a server.
It provides process database services.
It maintains, in user space, a database of all of the various attributes of a POSIX process that are not parts of a Mach task.
It is not a translator, and is not accessible via the namespace.
Rather, each process, when executed by /hurd/exec, is passed at startup a send port right for the /hurd/proc server, which is retained and used by the POSIX runtime library.
The process attributes include the process' self and parent IDs, its signal masks, its default environment and arguments, and its process and session groupings.
Its user and group credentials are stored in the /hurd/auth server, however.
The POSIX library function fork() registers new Mach tasks in the process database using the proc_child() remote procedure call.
It doesn't register a new port with the /hurd/auth server, however.
When a new child process is fork()ed, it shares its user credentials with its parent.
This is how the login program is able to modify the credentials of its parent process.
/hurd/auth
/hurd/auth is a server.
It provides authentication services.
It maintains, in user space, a database that maps from port numbers to sets of effective and available user IDs and group IDs.
It is not a translator, and is not accessible via the namespace.
Rather, each process, when executed by /hurd/exec, is passed at startup a send port right for the /hurd/auth server, which is retained and used by the POSIX runtime library.
Processes can obtain further send port rights via the /hurd/passwd server, which returns a send port right on the /hurd/auth server in response to a successful password validation, or directly from the /hurd/auth server via the auth_makeauth() remote procedure call.
Ports obtained directly are restricted, with one exception, to employing a subset of the available user and group IDs of the port(s) being used to make the remote procedure call.
Thus processes cannot augment their own user and group credentials.
The exception is when the set of effective user IDs incorporates the superuser ID.
And this is how the /hurd/passwd server is able to obtain the send port rights that it returns to its clients.
It, of course, has a send port right on the /hurd/auth server, which it obtained when it was executed.
This port right has the superuser ID as its effective user ID.
Thus the /hurd/passwd server is able to use the auth_makeauth()remote procedure call to generate send port rights associated with arbitrary user and group IDs.
The /hurd/auth server protocol comprises only three further remote procedure calls.
Processes can query their own user and group IDs via the auth_getids() remote procedure call, and servers and clients rendezvous with one another using the auth_user_authenticate() and auth_server_authenticate() remote procedure calls.
This rendezvous is part of a three-way authentication handshake that clients and servers perform with one another and with the /hurd/auth server, so that servers can authenticate clients.
When a client needs to authenticate with a server, both it and the server rendezvous via the /hurd/auth server.
The server sends to the client via the /hurd/auth server a send port right for an authenticated connection, and the client authorizes the /hurd/auth server to pass on its (effective) user IDs and group IDs to the server.
/bin/fakeauth
/bin/fakeauth is a server.
It provides authentication services.
It speaks exactly the same protocol as the /hurd/auth server, and in fact it forwards all requests to its own /hurd/auth server (whose send port rights it obtained at program startup), except for the auth_getids() request, to which it responds directly saying that the process has the superuser ID.
It is not a translator, and is not accessible via the namespace.
Rather, the /bin/fakeauth program executes a program arranging for /hurd/exec to pass a send port right for itself to the new process, rather than a send port right to the /hurd/auth server.
Because of the way that the three-way authentication handshake works, /bin/fakeauth cannot compromize a client-server rendezvous.
It is only a man-in-the-middle for the requests that are sent by the client to (what it believes to be) an auth server.
The server will be rendezvousing at the real auth server; and the responses to the requests from both client and server will be sent from the real auth server directly back to the client and server, not via the
/hurd/fakeauth server.
The purpose of /bin/fakeauth is to run processes in an environment where they believe that they are executing with superuser privileges.
However, they will in fact be executing with the privileges of the user who created the /bin/fakeauth process.
/bin/fakeauth is normally used in conjunction with /hurd/fakeroot.
/hurd/fakeroot
/hurd/fakeroot is a translator.
It is conventionally an active translator on /.
It speaks exactly the normal I/O protocol, and in fact it forwards all requests to its own root server (whose send port rights it obtained at program startup), except that it intercepts all requests to query and to set user and group IDs.
It maintains, in user space, a set of virtual user and group IDs for files and directories that it overlays on top of the real filesystem.
The purpose of /hurd/fakeroot is to run processes in an environment where they believe that they are able to change file and directory ownerships.
However, they will in fact be executing I/O operations with the privileges of the (usually unprivileged) user who created the /hurd/fakeroot process.
All ID changes are stored internally within the /hurd/fakeroot process.
/hurd/fakeroot is normally used in conjunction with /bin/fakeauth.
Information about the following daemons, servers, and translators is not yet available:
boot
init
mach-defpager
pfinet
usermux
fifo
ifsock
crash
symlink
firmlink
fwd
ext2fs
ufs
fatfs
isofs
ftpfs
© Copyright 2007 Jonathan de Boyne Pollard.
"Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.