how it works: hurd users

[Marcus Brinkmann]

Hi,

here is something that hopefully helps people to understand how the Hurd
user model works.  It is of course far from perfect, not complete, etc etc,
and it is certainly not supposed to be a replacement for proper
documentation (in fact, I don't even think it is adequate as a base for it).
I hope it is useful for developers and people who want to become developers,
and people who can turn this into good documentation, maybe as an addition to
the Hurd info manual.

My main goal is to collect facts which belong together, but are spread
around in the different sources, to ease the understanding for people
who would like to write documentation, but have trouble to get a foot into
the matter.  I will probably do this with other areas of interest in the
Hurd in the future.


2001-07-12  Marcus Brinkmann  <marcus@gnu.org>

        * Initial release.


How does it work?

Hurd Users
by Marcus Brinkmann


A Hurd user is identified by a port to the systems authentication
server auth.  The authentication server stores those user ids with the
port, and provides basic operations on them.  It can return the ids,
create a new port with arbitrary ids (root only) or create a new port
with ids chosen as a subset from the union of all provided ports.  It
also serves as a trusted third party in a handshake protocol to
establish trusted client-server connections.

The information the auth server stores in conjunction with a port are
four vectors of id numbers (uid_t, gid_t): the effective and available
user ids, and the effective and available group ids.  Any of these
vectors can be empty.  Any user id can occur several times, at different
positions, within the vector.

The effective ids are checked whenever an action requires the caller
to hold a certain user id for permission.  The available ids are not
checked, but the caller can turn an available id to an effective id
at any time.

By convention, the first available user id is the real user id in the
POSIX appearance of the Hurd.  The first available group id is the
real group id.  The first effective user and group ids are also the
effective user and group ids in the POSIX appearance of the Hurd
(unless they are not available, then the real ids are used).  Also by
convention, the second available ids, if available, are the saved ids
(file ids, file user ids) in the POSIX appearance of the Hurd.

The Hurd uses an unsigned long int for uid_t and gid_t, which means
that there are plenty of user ids.  The ids (uid_t) -1 and (gid_t) -1
is not available, as it is used by the POSIX interface as a return
value for getuid() etc. if no id is available, and used as arguments
to chown() if no change is requested.

Because any of the id vectors can be empty, some questions arise how
to map this situation to the POSIX appearance of the Hurd.  Asking for
the real or effective ids of such a no-user will provoke an error
(EGRATUITOUS).  The Hurd filesystem interface does not support files
owned by no-users.  However, the filesystems can support an additional
set of permission flags for such unknown users (mask is S_IUNKNOWN,
S_IREAD << S_IUNKSHIFT etc, defined in <bits/stat.h>).  They are
activated if S_IUSEUNKN is set.  Otherwise, the same permissions as
those for other users are granted.  (Note: It is not decided yet that
this is the best default).  (Note: The GNU fileutils don't support
setting or reading these bits using symbolic notation yet).

If the no-user creates a file in a directory he has permission to do
so (like /tmp), it will be owned by the owner of the directory.  Any
suid flags in the mode argument to open() will be cleared.

There are various helper functions to frob id vectors and do
authentication.  For example, <idvec.h> contains prototypes for
functions defined in libshouldbeinlibc, which can be used to
manipulate id vectors.  The filesystem libraries provide helper
functions to do initiate authorization protocols.

Some user space programs are available to change the user id ports of
processes, session groups etc (setauth, addauth, rmauth).


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de