Capabilities workshop, followup questions

[Bart van Leeuwen]

<rant>

Ok, I do not know how well this fits in with POSIX but..

For as far as I can see the following makes some sense:
A process is the 'owner' of resources and the unit by which capabilities
should be accepted. A thread is the 'schedulable' resource owned by a
process (It currently is not in BSD, but I think it should be)

This would imply that a thread can execute, but that any capabilities and
resources used should be checked against the process that 'owns' the
thread.

Imho this might solve quite a few questions with regard to threads,
including the one in the original post.

As for migrating to such a situation, regarding a non multithreaded
process as a process 'owning' one thread should work I think.

With regard to capabilities I think it is a good idea to look at the
purpose of threads vs processes. Imho the purpose of threads is to create
multiple paths of execution within a given piece of code. As far as I can
see threads normally share most (if not all) resources. Processes on the
other hand offer a way to create a 'unit' that holds execution, resources
and capabilities in one. Processes normally have private as well as
shared resources. I'd argue to see this as a mostly administrative
'unit' and as a result, let it do such administration as capabilities as
well. I'd think that since threads are mostly concerned with executing
actual code, that it would not be a good idea to add anything that would
make that execution less efficient (and I think such complexity a having
capabilities might very well add such complexity)

Just my few cents ;-)

</rant>

Bart van Leeuwen
-----------------------------------------------------------
 mailto:bart at ixori.demon.nl  -  http://www.ixori.demon.nl/
-----------------------------------------------------------


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message