[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: passive translators

From: Wei Shen
Subject: Re: passive translators
Date: Thu, 21 Jun 2007 21:57:00 +0800


> I proposed two solutions in last mail. In solution a), the translator is
> started chrooted. So the file node, parent, and target are respectively:
> /foo, /, and / in its eyes; and /chroot/foo, /chroot, and /chroot in
> reality.

> I am not sure if this translator can still serve non-chrooted processes.
> Even if it can not, I do not think this is a problem, so long as it can work in the chroot domain.

We discuss an example where this causes problem in the critique
(think: client with a different global name space looks up .. at the
translator's root).
So a port of /chroot is returned to the client? If the client can access /chroot/foo, I think it can also access /chroot, or you may mean that foo has a different parent node in the client's name space, which I think can not be achieved by chroot. 
I reviewed your letters once again and tried to read some code. Is it that chroot information is binded to file handles? So that, once a process enters /chroot/foo, it can not escape /choot by going back to .. recursively? I have not thought that. In my imagination, every lookup will create a new file port and recompute the chroot information (if it is binded with file handles) according to the client, but not inherit the chroot from the cached file handles.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]