Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Now, let's see what you suggest for this second case.
> 
> > Then I think a reasonable way to divide the work is to
> > 
> > 1. Have a library function (libexec, libbfd, wherever) that takes a
> >    file port as argument and returns a new file port to the
> >    interpreter file, as well as any modifications to the argument
> >    list.
> > 
> >    Note that the most common case will be the interpreter ld.so. I'm
> >    not sure how the double-interpreter case works, where a #! script
> >    is interpreted by /bin/interpreter, which in turn is "interpreted"
> >    by ld.so.
> 
> I am not sure if you suggest that this code is used in the exec server or in
> the user's code.

I was suggesting that it be in the user's process. If necessary, it
could be in the file server I guess. I don't think it belongs in the
exec server, as it shouldn't require any privileges that the user
process or file server doesn't have.

> The reason is that you can run executables without having read
> rights.

To me, executable-but-not-readable files don't make much sense (in the
non-setuid case). I mean, you could always use LD_PRELOAD to replace
some common function (main, printf, open, whatever) with code that
dumps the current address space to a file. I'd be happy do stop
pretending that this case works securely, by making executable,
non-readable, non-setuid files either readable or unexecutable, but
perhaps that breaks POSIX compliance?

Just one more short comment, I have to read this more carefully
tomorrow.

> Let's say for a moment that instead reusing your own address space, you
> always create a new one.  That means that you can have both tasks exist in
> parallel.  Before the new one can run, the PID (and other state) has to be
> reassigned to it.  But then there is a short time where it might be possibly
> allowed to have the old task running in a near-dead state that can be used
> to transfer some data and handles from the old task to the new one.

This sounds like a nice and clean way to get the transfer of handles,
I was about to suggest it myself ;-). When done, either the old task
has to commit suicide, or we give the new task a task control handle
so that it can kill the old task before calling _main.

Best regards,
/Niels