Aloha -
My recent experiments with 'netmsg' have lead me to investigate the operation of Hurd's exec server, and I've got a few questions.
First off, the current obstacle to exec'ing files over netmsg is the need to operate the memory_object protocol over the TCP/IP connection. libpager has a problem with this, because it can't handle multiple clients. It needs to, because in a multi-node environment a file server is likely to be interacting with multiple kernels using memory_object calls. Also, my test program can mount denial of service attacks against the kernel by grabbing libpager's only available client connection for a given file before the kernel does.
So, I'll modify libpager to handle multiple clients. Not trivial, but it seems necessary and correct.
However, the protocol exchange over the network connection isn't what I expected. The failing vm_map turns out to be running on the server, not the client!
Think about this for a minute. We've mounted a remote file system and tried to exec a file on it. I expected the client to be mapping the file, which is on the server, not the other way around!
The reason is that the failing vm_map arises from the exec server's attempt to examine the ELF header of /lib/ld.so. When the client called file_exec_file_name, it passed a bunch of ports across the network connection, including INIT_PORT_CRDIR. The file server then passed that along to the exec server (running on the server), which examined the file (no network ops needed; both the exec server and the file are on the server), determined the need to map /lib/ld.so, did a dir_lookup on INIT_PORT_CRDIR (this went back across the network), and then tried to map the file's ELF header into its own memory space. Not the new process's memory space, mind you; it maps it into its own memory space!
One question is whether the exec server really needs to do a vm_map to examine an ELF header. A simple read would suffice. Which should be preferred?
A more serious question is why the exec server is running on the server side at all. Shouldn't it be running on the client? Then the only network operation it would need is to map the one file that it's trying to execute.
Examining diskfs_S_file_exec reveals some interesting behavior. The file server caches a port to its exec server, so the same exec server gets used by all of its clients! Furthermore, it gets the exec server in the first place by looking up _SERVERS_EXEC in its own name space, not the client's!
Shouldn't the exec server be looked for in the client's name space?
While trying to figure all of this out, I googled around and found the discussion on this list about the EXECSERVERS environment variable, which has apparently been deprecated in favor of the remap translator. I can't get remap to work, and it's real simple, so I suspect that it's currently broken. Yet even if it were working, I can't see how it could affect the choice of exec server, since it only modifies the client's name space!
I'm thinking that maybe the C library's exec() should lookup _SERVERS_EXEC and pass it to the file server in the file_exec_file_name call. Then, if SUID execution is being requested, maybe the file server ignores that and looks up _SERVERS_EXEC in its own name space.
What do you think?
agape
brent