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
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
