Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Plug and Play
Beyond filesystem translators, there are a few processes to which all others have a connection. The first of these with which a user will interact is the password server, present in the filesystem, which handles interactions with the /etc/passwd file. It provides a simple mapping between passwords and authentication tokens.
Because the password server is just another process, it’s trivial to replace. Irrespective of how the password-to-authentication mapping is performed (via a simple text file, NIS, LDAP, etc.), the interface remains the same. Adding a new authentication mechanism is therefore fairly simple.
The authentication tokens handed out by the password server are ports created by the authentication server. This arrangement provides mechanisms for the root user to create new authentication ports, and to compare the rights granted by a pair of ports.
Processes communicate with their authentication server via a port that’s set up before the process is created. Therefore, all processes on the same system don’t have to use the same authentication server. A program consisting of multiple processes might want to designate one of them as an authentication server, which would be used by the others to determine how they communicated. Other users on the system then could run other processes that interacted with this program, as long as they met some arbitrary requirements for the authentication server.
The other core server is the process server. This is fairly similar in concept to the process table in a BSD-like kernel. It maintains a mapping between POSIX-style process IDs and Mach "tasks" (processes) in the underlying microkernel. It stores some metadata about each process, for use by tools such as ps and top. It’s also a central registry for IPC. Any process can register a Mach port with the process server.
Since the process server is the only way of getting access to the process table, something equivalent to FreeBSD "jails" or Solaris "zones" could be achieved by a user running her own authentication, process, and password servers, giving a different translator as the root directory port to the newly jailed process. None of this activity requires any special privilege, although giving the new process tree its own IP address would require it to have different instances of a few of the network-related servers, which might require root access for them to be allowed to bind to the specified IPs.