Re: firmlinks and chroots

[Marcus Brinkmann]

Hi,

some additions.

At Tue, 11 Sep 2007 23:43:53 +0200,
Marcus Brinkmann wrote:
> Some people suggested that somehow the chroot setting should be stored
> in the passive translator setting. 

Note that the problem can be generalized, and is not limited to
firmlink+chroot.  Another example would be a process that is monitored
with rpctrace.  If it installs and activates a passive translator,
that translator is not monitored, but arguably it should.


[...]

> The system, and each user, start a "translator server" at startup.
> This server attaches itself to a number of file nodes (the list is
> taken from a configuration file, for example).  Whenever a node it
> covers is accessed for the first time, it takes the translator setting
> and other configuration (like chroot-ing, or whatever) for that node
> in its configuration file, and then starts an active translator with
> that configuration on that node.  Thus, it replaces itself with the
> "real" active translator on that node, and all accesses (including the
> first) are then resolved on that new, actively translated, node.  Hurd
> translators can (if not already, then at least in principle) be
> "stacked" on a node, so that the "translator server" is still running
> "beneath" the active translator it started.  When that translator
> dies, for example to release all resources after a timeout, accesses
> go to the "translator server" again---this feature provides race-free
> transparent restart of translators, just as it exists with passive
> translators.  (Does your solution also fulfill this requirement of
> atomic, transparent restart?).  With this proposal, passive
> translators are not used anymore.
> 
> Why does this fix the firmlink problem?  When a chrooted program wants
> to install a firmlink translator, it can only start it as an active
> translator, which can not extend its authority.  The equivalent action
> to installing a passive translator in the new system is to change the
> user's "translator server"'s configuration file, something that the
> chrooted program presumably has no authority to do.  It could start
> its own "translator server" (and would be encouraged to do so), but
> this "translator server" also would not have excess authority, thereby
> limiting its possible actions.
> 
> The only feature of passive translators that this proposal does not
> provide is decentralised storage of the translator settings.  You
> might see this as a disadvantage.  On the other hand, the proposal
> decentralizes the *policy* of how to "activate" translators, and that
> is much more important in my opinion.

I think the proposal can be extended to decentralize storage of
translator settings as well.  However, there is no obvious
generalization so it is not clear which of the alternatives is best.
Some ideas:

* Passive translators can be stored in inodes, when they are
  encountered the filesystem propagates the request to install an
  active translator to the translator server of that user.  (This
  matches most closely what is happening now, just that the active
  translator is not started by the filesystem but by the user owning
  the node).

  Has a lot of unpleasant denial of service attacks, but none that are
  in a different class than the ones we already have.

  Requires special support in the filesystem for reacting to passive
  translator settings.

* Passive translators can be stored in inodes.  The C library can see
  these settings, and either start an active translator itself (this
  works best with private namespaces or private parts of a global
  namespace---it's basically what's going on magically with /dev/fd/N,
  just that there is no extra process needed), or contact the
  "translator server" to let it start an active translator.  (Extended
  attributes could hint at what should happen).  This does only work
  easily for nodes owned by the same user.

  If the node is owned by another user, that other user's translator
  server needs to be contacted instead.  This is where it gets
  complicated to carry over the old design, but arguably that's what
  should happen.

  Does not require special support in the fileserver, passive
  translator settings are just provided to applications (as extended
  attributes, for example).

(Note: Both solutions require fileserver support for active translators).

These are just starting ideas.  These issues are complicated enough
that they can't be decided in a hurry, and I don't have time for a
thorough analysis.  I just want to illustrate that decentralized
translator settings are not necessary lost with my proposal.  So,
passive translators may survive, but they would never be activated by
the filesystem server they reside on.

Thanks,
Marcus