Re: thread ids, task ids and subsystems

[Marcus Brinkmann]

On Tue, Apr 08, 2003 at 09:59:40PM +0200, Niels Möller wrote:
> > So, although this definitely introduces quite hurdish concepts into the task
> > server, I don't really see a way out, unless you want to route *all* task
> > manipulating calls through proc itself (something you didn't want to :).
> 
> You're thinking about things like the protocols for transfer of port
> rights?

Definitely.

> I'd expect that every server have to implement that, except
> servers that have *only* privileged calls. Or provides its own
> protocols for transfer (like the memory server?).

Well, that's what I was thinking about, and I couldn't think of a solution
without the port concept.
 
> > Also, the task server will be special in that it provides one thread for
> > each processor.  But you don't want as many ports representing the same
> > task (one port per processor).  So I think that there should be special
> > wrapper code that automatically calculates the "port number" (really: the
> > thread id of the receiver in the task server) by adding the processor number
> > (starting at 0) to the thread number in the thread id of the task "port"
> > (which is really just the base thread id in the task server together with
> > the number representing the task - favorably simply the pid).
> 
> Special casing seems a little ugly. Have I missed something if I
> believe that this matters mostly for the calls for creating and
> killing threads? Then I'd suggest that only the thread calls be
> special cased; use one thread for each cpu that handles thread
> creation, and single thread for other task-related calls.

I think that if a special case is necessary, it would be a flag per
interface, and I think that special casing some calls in a whole set of
interfaces would be ugly.  So, all calls to the task server would then be
special cased.

> (Either this, or the other extreme, let *every* hurdish port anywhere
> in the system have one receiving thread per cpu).

Yes, that was the other solution that came into my mind, and in fact I think
that this probably wouldn't be too bad at all.
 
> > I have wrapped my mind an hour or so around solutions that try to avoid such
> > a sophisticated access control system in the task server itself, and just
> > exploit the accounting ID grouping and other things, except that they just
> > don't work and don't offer the criteria we need.
> 
> I'd love to help (or be educated as to why accounting id:s don't work
> ;-). One way to avoid the problem might be to say that a task can call
> the task server to manipulate itself (and perhaps tasks with matching
> account id) directly, but enybody else have to go via proc. Then you
> lose the property that a task can give away access to it's task port
> to any other task, I'm not sure what the impact of that restriction
> is.

Well, the "every task can manipulate itself and other tasks with the same
accounting id" rule is the first I came up with.  But what do you mean with
"go via proc"?  You really have to come up with a concept for "go via proc".
Now, you might say that proc gets a special accounting id that is privileged
(the root accounting id if you want), but then you still have to tell me how
accounting ids are given (are they per user?), and how you want to implement
"go via proc".  You would need to have a thread_control call and a
proc_thread_control, and so on for all calls where you might have to "go via
proc".  Any way I approached this it ended up with silly constructs like
that.

And then there are some further consequences of not having task ports.  For
example, you possibly couldn't use another users crash server, even if you'd
trust it.  Proc would become an authority on task control access, and users
couldn't delegate it to other users without special support in proc or
giving total access to the user id.

Your description of what accounting ids are to solve is correct.  I just
think that they don't work as authentication tokens as well.

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/