> 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 _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
