Re: A proxy of the proc server for translators

[zhengda]

olafBuddenhagen@gmx.net wrote:
> > 3. If the translator is set in the passive mode, it is started by the
> > file system server. It seems that I don't have a chance to override
> > its  proc server.
> >     
>
> These should be fixable by reversing the command I think:
>
> settrans -afgpc /root/socket2/2 proc_proxy /root/hurd/pfinet/pfinet -i eth0 -a 
> 192.168.2.11 -g 192.168.2.1 -m 255.255.255.0
>   
In this case, proc_proxy must work as a translator, and meanwhile, have 
the ability of running another translator just as settrans does.
But it should be feasible.
>   
> > 2. when the proc server gets the request, it is always looking for the
> > process information from the remote port of the caller. When an RPC is
> > forwarded by the proxy, the process information of the proxy is
> > changed  and the real proc server still doesn't know anything about
> > the process  who sends the request.
> >     
>
> Hm... I'm quite at a loss here :-(
>   
The RPCs in process.defs are handled a bit different by the proc server.
When the proc server receives a RPC request, the proc tries to find the 
process information of the requester by using reqport_find(). The 
request port (of the caller) is passed to reqport_find(). As a result, 
the process information returned by reqport_find() is of the process who 
directly calls the RPC. Here is the code (in processServer.c):
     process = reqport_find(In0P->Head.msgh_request_port);
In the case of proc_proxy, when proc_proxy "forwards" the RPC, the 
process information set or got by the RPC is of proc_proxy, but not of 
the translator because the caller of the RPC is always the proc_proxy in 
the proc's eyes. It's not what we want.
So in order to make the proc proxy really work, the proc proxy should 
cheat the proc server that the request is from the translator. I don't 
know if it's possible to do it in the current implementation of Mach. If 
it's possible, I wonder if there are some security issues.

I don't think the proc proxy is very useful in the case of pfinet 
because we only want to get the pseudo master device port to access the 
"hypervisor". This solution is too complex.
But it should be useful to create a subenvironment in the future, at 
least I hope:)
I think that it's more useful to create a translator that helps the 
socket server such as pfinet get the port of accessing the network 
interface (virtual or real). That is, the pfinet can get the port of 
accessing a network interface by calling file_name_lookup().

Best,
Zheng Da