Re: exec server behavior

[Richard Braun]

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