Re: new exec server protocol

[Marcus Brinkmann]

On Tue, May 20, 2003 at 11:59:10PM +0200, Niels Möller wrote:
> > 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.

Well, that's just one of the many ways to get around that, yes.  I guess it
is just too hard to make this work correctly.

> 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?

Good question.

> > 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.

Such issues are answered when looking at the details.  For example, proc
assigns PIDs to every task.  The current proc interface has a feature
"proc_reassign" that makes a (new) task reuse the PID of another (old) task. 
This also leads to the termination of the latter (old) task.  Alternatively,
the old task could get a new PID, or the PIDs could be exchanged.  However,
a normal chain of events would be:

Old Task                New Task
Create new task
setup pager for it
start new task
                        fault in
grant initial pages
                        read the bootstrap thread id from somewhere (stack?)
                        send startup message
reply startup message
                        process startup message

But then, what?  What we want to do is to assign the pid to the new task,
die, but we also want the new task to wait until it actually got the pid, to
avoid a race where it would only get its pid after main().
If old task donates its task port, new task could possibly do the reassign
itself

reply startup msg (has task port)
                        proc_reassign ()

But I am not sure it is good for new task to get the old task port.
Or proc could swap the pid:

                        send startup message
swap pid
reply startup message
suicide                 process startup message

I think I like this better.  In the suid case things are a bit simpler
because we have the filesystem as third man and helping hand.

Thanks,
Marcus




-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/