Re: "network administrator" in GNU/Hurd

[Farid Hajji]

> When I am reading books on using Unix, like "(not so) Short
> Introduction to LaTeX" and "The Art of Unix Programming", I
> frequently see phrases like "ask your network administrator to
> do/install...". Will Hurd abolish these pharases? For sure there
> will be need of network administrator but why should I care about
> her if I am allocated, for example, 128 MB of ram, 1 GB of disk
> space and 10Mbps bandwith?

The traditional (pre-Hurd) practice is to have a sysadmin with higher
priviledges, when it comes to setting things up, which affect the
whole kernel. This is necessary, because some resources affect the
system as a whole. Filesystems (mounting), network settings, loading
kernel modules, ... are such examples.  If a single (non-root) user
were allowed to do such things, she could inadvertantly misconfigure
the system, and make a lot of other users angry.

A vast improvement to this is FreeBSD's jail(8) system.  This is
an enhanced chroot(2)-ed environment, which allows you to offer
"virtual unix hosting" on a single machine. In practice, you create
many jails and populate them with a complete FreeBSD system (or a
subset thereof if you prefer). Users which are inside the jail are
operating in a virtualized environment. They can even have root
acconts without harming other people in neighboring jails. The reason
for this is because root priviledges in jails work differently
(e.g. you can't shutdown or reboot the host machine, only your own
jail). Actually, many companies offer jail-based Unix virtual hosting
to customers, as a cheaper alternative to dedicated (hardware)
hosting/colocation. Users of jails can be their own sysadmin, install
any software they want etc...

The Hurd has a different way to get rid of root's omnipotence.  The
main reason is that many functions, which ran previously in the kernel
(e.g. file systems, network stacks, ...) run now as user-level
tasks. Another reason is the way how the Hurd's namespace (the global
filesystem) is cleverly used to attach translators.

In the Hurd, priviledges are delegated in a hierarchical manner.  root
is in control of the global namespace (just like any other Unix
system), but may set permissions on subsets of the namespace to allow
users control over their environment. Users may themselves delegate
their rights to parts of the namespace under their control in a
differentiated manner.

An example: User joe has full access rights in $HOME. He writes a
filesystem translator, which taskes a big file $HOME/bigfile as a
backing store and provides a filesystem-view of this file to other
users. Clearly, the access policy of the new translator is fully under
the control of joe. He can set up ACLs (access control lists) or
regular Unix rwx permissions if his translator permits this. He could
also use different semantics, e.g. by fetching the permissions of
other users from an LDAP server, acting differently, depending on the
phase of the moon, or whatever. The point here is this: joe can't
assign higher priviledges to other users than what he is already
permitted to do. Only because he has full access to $HOME/bigfile, can
he restrict those rights to other users. OTOH, joe should not be able
to access files of other users without their permission.  Recursively,
users who got permissions from joe to act on a subset of joe's
filesystem $HOME/bigfile can also set up their own translators,
restricting rights to other users even further.... You get the idea.

Similarly, a network administrator will derive her rights from root
and could delegate those rights selectively to certain classes of
users: Users can e.g. settrans pfinet or any other network protocol
translator of their choice somewhere in their namespace, therefore
able to plug in a complete network stack without having to bother root
or a network admin.

However, users are still required to have special permissions to
access shared hardware. For example: if users' network stack
translator needs access to a network interface card, the user would
still need permission to access this hardware, which could be
potentially used by other people as well. Right now, people are trying
to move device drivers out of the microkernel. As soon as this
happens, root (or a network admin) could set up an access policy in
the (userland) device driver tasks, e.g. permitting any user (or a
class of users) access. If this happens, you would be able to attach
your own network translator to the device driver task for the network
interface and send/receive frames.

Of course, not every user should have full, unrestricted access to a
network card. Why? If the card is used concurrently by many users, and
an ethernet frame is received by the card, where should this frame be
delivered to? In theory, it could be multiplexed (copied) to every
network translator that is attached to it. This in itself is not a
problem, but from a security point of view, it may not be such a good
idea.  Perhaps some frames are only destined to a subset of
priviledged users? You don't want everyone sniffing everything that
comes in, perhaps hijacking connections, etc... So there is still need
for policies here. FreeBSD jails solve this particular problem by
associating a single IP address to every jail and demultiplexing
the incoming stream of IP packets based on the IP address. In the
Hurd, another mechanism should be designed, which could perhaps act
at a lower level (frames).

Actually, it would be nice to port the jail mechanism to the Hurd.  We
could perhaps even rename it to matrix(8)... ;-) Anybody volunteering?

> --subedi

-- 
Farid Hajji. http://www.farid-hajji.net/address.html