Hi,
Could you please give some explanation on "PFINETSERVER=fd:3 myprog
3</path/to/pfinet"? What does "myprog 3<" mean, the naming closure?
On 6/21/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote:
There is a bit of confusion here, I'm going to try to be more
specific, please indulge me.
Thanks!
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?
I have not expressed clearly. Let me describe a scenario below. I do not
think my idea is a good one, but I think it can work.
(1) Assume a chroot process invokes "settrans -cp /foo /hurd/firmlink /".
(2) The fs server will associate node /*foo* (/chroot/foo) with translator *
firmlink*. Since the fs server knows the quest is from a chroot process,
it can save a chroot attribute "/chroot" (it is a string representation of
the chroot path, but not a handle or other expressions of capability), in
addition to the translator command "/hurd/firmlink /".
(3) When the passive translator is activated, we have two choices:
a) Let the fs server check for if any chroot attribute exists and start it
as a chroot process with */chroot* to be its virtual root.
b) Let the fs server pass the chroot attribute to the translator when it is
started, and the translator should add the chroot path in front of any path
argument ("/" in this scenario) given to it. So the command to start
firmlink equals "/hurd/firmlink /chroot/"
Approach b) requires the awareness and cooperation of the translator, and we
assume it can be trust.
Regards,
Wei Shen
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
