[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
passive translators
From: |
Neal H. Walfield |
Subject: |
passive translators |
Date: |
Wed, 20 Jun 2007 19:00:50 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
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.
- Re: Defualt socket server overriding, (continued)
- Re: Defualt socket server overriding, Wei Shen, 2007/06/20
- Re: Defualt socket server overriding, olafBuddenhagen, 2007/06/20
- Re: Defualt socket server overriding, Neal H. Walfield, 2007/06/20
- Re: Defualt socket server overriding, Thomas Bushnell BSG, 2007/06/20
- Re: Defualt socket server overriding, Neal H. Walfield, 2007/06/20
Re: Defualt socket server overriding, Wei Shen, 2007/06/20
- Re: Defualt socket server overriding, Neal H. Walfield, 2007/06/20
- Re: Defualt socket server overriding, Wei Shen, 2007/06/20
- Re: Defualt socket server overriding, Neal H. Walfield, 2007/06/20
- Re: Defualt socket server overriding, Wei Shen, 2007/06/20
- passive translators,
Neal H. Walfield <=
- Re: passive translators, Wei Shen, 2007/06/21
- Re: passive translators, Neal H. Walfield, 2007/06/21
- Re: passive translators, Wei Shen, 2007/06/21
- Re: passive translators, Neal H. Walfield, 2007/06/21
- Re: passive translators, Wei Shen, 2007/06/21
- Re: passive translators, Wei Shen, 2007/06/21