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