Re: passive translators

[Wei Shen]

Hi,

> 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.

 

Wei