There is a bit of confusion here, I'm going to try to be more specific, please indulge me.
At Thu, 21 Jun 2007 00:25:33 +0800, Wei Shen wrote: > The fs server or the translator? What is an fs server? In the Hurd, translators are file systems: some are one node file systems; and, some expose complex hierarchies. Translators are linked together using the file_set_translator method. > I think at least the fs server should > know. Am I right? You are right: when a client invokes an operation on a capability/file handle, the server knows that the file handle is chroot'ed: it has a capability that it returns when resolving `..' via the file handle. You talk about associating a symbolic name with this. The question is what is the right symbolic name for it? This depends on the context, and that is exactly the problem: naming contexts as represented by capabilities are not persistent. > The translator needs not to know whether a process is chrooted or not, it > just always adds (for any process) the virtual root argument saved when it > is associated with the file node. I assume that you mean the file handle that is passed to the chroot'ed process that it uses as its root, and not the on-disk node. First, the file handle is not persistent: it is destoryed when the system is rebooted. How do you recover this information? Second, the chroot'ed process can create a passive translator and then stat it. This causes the translator to start an active translator. Currently, when a passive translator is instantiated, the resulting translator's name space is set to the parent translator's. This is because the passive translator is a string without a naming context. This allows the chroot'ed process to escape from its jail. The problem here is how to preserve the naming context. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
