On Wed, Aug 24, 2016 at 07:24:16PM -1000, Brent W. Baccala wrote: > So, I'll modify libpager to handle multiple clients. Not trivial, but it > seems necessary and correct.
Don't start that immediately, wait for more discussions. I'm not so sure it would make sense to support more than one client. > 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? I agree that read should be preferred. In a completely separate non-existent issue, it would be the only way to support nommu systems. > 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? You're getting into the same kind of "light virtualization" issues we have with e.g. chroot. Many operations are done by servers, from their execution context, and this breaks that kind of behaviour. I started thinking about these only a couple of weeks ago, and so far the only solutions my limited brain can come up with is to either use the client context (by perhaps passing its root) but that could cause security issues, or have a third-party like auth (or proc or whatever) store enough of this context that the server can use it. -- Richard Braun