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 dholl...@netbsd.org
