[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new exec server protocol
From: |
Marcus Brinkmann |
Subject: |
Re: new exec server protocol |
Date: |
Wed, 21 May 2003 00:50:43 +0200 |
User-agent: |
Mutt/1.5.3i |
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/
- new exec server protocol, Marcus Brinkmann, 2003/05/20
- Re: new exec server protocol, Niels Möller, 2003/05/20
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/20
- Re: new exec server protocol, Niels Möller, 2003/05/20
- Re: new exec server protocol,
Marcus Brinkmann <=
- Re: new exec server protocol, Niels Möller, 2003/05/21
- Re: new exec server protocol, Niels Möller, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Niels Möller, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22