per-process namespaces

[David Holland <dholland-tech%netbsd.org@localhost>]

As a few people have heard, I thought up a way to implement
per-process namespaces reasonably cheaply without requiring massive
rewrites of everything. It is kind of a hack, but not super awful.

Preliminary patch is here:
   http://www.netbsd.org/~dholland/tmp/namespaces-20151127.diff

It at least mostly passes anita test, but hasn't itself really been
tested as the userspace component hasn't been written yet. There's
also no man pages yet.

Comments on the approach? (And if you spot any obvious bugs in the
code, would be happy to hear about that too.)

The basic principle is that there are two namespaces (ordinary and
privileged) and setugid programs automatically switch to the
privileged namespace (which only root can muck with) by default. Also,
namespaces cannot be modified once installed and inherit from the
previous state. With these mechanisms, unprivileged processes can
manipulate their namespace arbitrarily without compromising
anything. Or so I believe. This is desirable for e.g. sandboxing GNOME
applications or enforcing bl3 in pkgsrc builds.

The scheme works by installing rules of the form (dir-vnode, name) ->
target-vnode. It is the responsibility of whoever crafts the namespace
to install coherent rules; e.g. a simple chroot requires two rules of
this form:
	(/chroots/foo, ..) -> /chroots/foo
	/ -> /chroots/foo)
where / is a special case of the rule table key.

The rules are ordered and the intent is that they behave like a series
of string substitutions on absolute pathnames; to make this work they
are supposed to be loaded back-to-front and the lookups are done in a
very specific fashion. If I have stuffed this up (it's not entirely
trivial) please let me know.

-- 
David A. Holland
dholland%netbsd.org@localhost