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
