Default database / namespace

[Robert Wittams]

> -----Original Message-----
> From: owner-eros-arch@eros-os.org [mailto:owner-eros-arch@eros-os.org]On
> Behalf Of Jonathan S. Shapiro
> Sent: Tuesday, July 04, 2000 2:51 AM
> To: eros-arch@eros-os.org; Kragen Sitaker
> Subject: Re: Default database / namespace
>
>
> 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.

Agree 100% ! I think that this is a very important thing to get right.
Having the namespace entirely seperated from the kernel is almost certainly
a good thing, as it allows us a lot of flexibility - which has to be kludged
in on windows/unix/other things with integral namespaces - eg GnomeVFS and
the combination of structured storage / internet explorer. Also we can
hopefully do without any kind of "filesystem in a file" with a randomly
different interface - see Berkely DB / MS Structured Storage for infuriating
examples ;-)

One thing that still has to be considered is how to ensure that doing a
query
which is computationally intensive does not infringe on other users of the
machine.
If I understand correctly, this should be covered by the reserve mechanism,
and is
an issue for all domains anyway...

> 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.

Yep, this is a pretty obvious security flaw, as is evidenced by the fun
of /tmp races on unix amongst a whole host (pun not intended) of other
things.
It is a very overt channel ;-)

> 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.

Do you have a link to a summary of his argument? or is it in the mail
archives?

> 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").

I don't see a great distiction between env vars and entries in a namespace,
am I missing something?

> 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.
>
Yeah, this is an issue I need to read up on ;-)

I don't think a global namespace is necessary or desirable (not considering
the
auditing issue which I am not familiar with). The OS that I think shows this
best
is Plan 9, in which any process can have a different namespace. This design
is soon
to be implemented in Linux AFAIK, which should be interesting. In eros we
can go a
bit further by making the namespace entirely optional.

Thanks
Rob