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 <neal@walfield.org> 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