Re: Default database / namespace Jonathan S. Shapiro (shap@eros-os.org)
Mon, 3 Jul 2000 21:50:44 -0400

I have been pondering this discussion of namespaces, not wishing to respond in haste. After some thought, I have two reactions overall:

  1. Some form of namespace is required, and it is good that it should be flexible. The KeyKOS directory object provided a service similar to UNIX directories. It held general capabilities rather than just files, and did not provide permissions. The simplicity of a set of (name, capability) pairs is very appealing, but it may not be the best design. Exploring alternative designs seems like a fine idea.

That is, we need a good namespace building block.

2. A single global namespace is an unmitigated disaster and should be avoided at all costs, because it is an unclosable security hole for reasons discussed in the previous messages on this topic.

I should acknowledge that Paul Karger does not agree with me about (2). He argues, and I think his argument needs to be understood and carefully examined, that a unified namespace is essential to providing (human) auditability so that one can determine what has been done in a system and also so that one can find all nameable references to a sensitive object.

In a persistent system, I am not convinced that locating all nameable references has the same utility as in a non-persistent system, as there are likely to be references from persistent processes that are very long lived. This said, the issue of auditability is an important one. Paul's argument, I think, comes in the context of multilevel secure systems, but the audit issue is a general issue.

I suggest that what we really need to discuss is whether, in principal, there is any justification for audit, and also whether in the absence of audit we can achieve adequate confidence in the security state of any given system. This will determine whether a global namespace is appropriate.

In rejecting a global namespace, I want to be clear that I do not reject shared namespaces in general. If you and I wish to share a common directory, one of us can build the directory and ship a capability to it to the other
*provided* that we are authorized to communicate. This is a fine design
pattern. However, there is absolutely no reason why your name for that directory and mine need to agree (though this raises a secondary design issue of "environment variables").

In such sharing, the main concern is managed storage and assurance of privity in reclamation. That is, if I share an object with you I need to take some care about which space I delete lest I unintentionally (or intentionally) damage the object. Some namespaces may wish to have implied contracts of durability, and this is an underexplored issue in the design space. Norm has some comments written up on durability and I hope he will post the link.