Using Directories to Implement a Local Mail System

In the Monads systems a directory is a user-level file module in the persistent memory which maps symbolic names onto module capabilities. An example of a directory with type manager routines is shown in the following diagram.

Each persistent process initially receives a module capability which gives it access to a module. In a discretionary system this module is typically a directory. This in turn typically holds a capability for standard software and for modules which are shared on a systemwide basis.

In order for a process to enter a capability into a directory of another user (to give him shared access to a module) the process must have a capability for the other user's directory with an access right which allows an entry to be made. It can obtain such a capability from a directory set up for this purpose (the "Public Mailbox Directory" or PMD) and shared on a systemwide basis, reachable from the process's first capability. This contains a list of symbolic user names and, for each user, a capability for his private mailbox directory.

A user's mailbox directory is basically a normal directory into which other users deposit capabilities for modules (typically but not necessarily for data files) to which they wish to give him access. The sender of mail will need a capability (taken from the PMD) which gives him the right to create an entry in the mailbox. The following diagram illustrates the directories involved and (a first approximation of) the access rights needed for sending mail.

How does an entry get into PMD? The answer is that a user must be able to create a mailbox of his own, for which purpose he needs access to a capability for a type manager with creation permissions. Using this he creates a mailbox. He then places the module capability for his own mailbox into the PMD. This in turn means that the capability which he obtains for the PMD must give him the right to create a new entry in it. (He can of course choose not to receive mail from the public by not making an entry in the PMD.) But if he can create his own entry, he may also want to delete it later. However, if he is given a general right to delete entries then he can maliciously remove the entries of other users from the PMD! This problem can be avoided by having an additional entry point in the type manager for directories, "delete my entry", which allows a caller to delete only those entries in a directory which he has created.

This idea is easy to implement in Monads because the stack of a persistent process is implemented (like a file) in an address space which has a unique identifier. When a user calls a "create entry" entry point of a directory the type manager can obtain from the kernel the unique identifier of the process, and from this the unique identifier of the owner of the process. This is then stored with the entry which is created. When "delete my entry" is called, the type manager can obtain the unique identifier of the owner of the calling process in the same way as in the routine "create entry". The entry is deleted only if the identifier of the caller matches the identifier of the creator as stored in the entry.

This means that the capabilities (and their access rights) actually needed to create a mailbox and insert it in the PMD are as shown in the following diagram.

The same "delete my entry" technique can be used to allow a user to delete entries which he has made in other users' mailboxes without risking that he destroys mail sent by different users.

Finally, how can a sender be sure of the identity of another user to whom he sends mail, and how can a recipient be sure who has sent mail to him? The latter is easy to answer: as we saw in the discussion of "delete my entry" a type manager records the unique identifier of the sender of mail when it makes the entry. The sender cannot influence this, because his identifier is taken automatically form his process; he does not supply it himself. In the same way the sender of mail can be sure about the recipient in that he uses the mailbox capability placed by the recipient into the PMD, where his unique identifier has been recorded.

It is worth noting that all of this happens above the level of the kernel, so that uses can develop quite different directory type managers to behave according to their wishes, e.g. mailboxes which filter mail and return unwanted messages to the sender, or which further sort mail by sender into different mailboxes, etc.

It is also worth noting that the entire system, which both allows users to pass capabilities for shared files to other users and to send mail to them, is implemented using only a single relatively simple piece of software: a directory type manager.

Finally, only a very small extension is needed to extend this technique to enable it to function in a (local area) network of homogeneous Monads computers which have a distributed shared virtual memory. To find out more about this, click here.

Keedy, J. L. and Vosseberg, K. "Persistent Protected Modules and Persistent Processes as the Basis for a More Secure Operating System", in Proceedings of the 25th Hawaii International Conference on System Sciences, 1992.

Keedy, J.L. "A Model for Security and Protection in Persistent Systems", Microprocessors and Microsystems, 17, 3, 1993, pp.139-146.