Capabilities workshop, followup questions

[Robert Watson]

On Mon, 19 Jun 2000, Bart van Leeuwen wrote:

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

This was pretty much the conclusion we came to at the workshop, although
it was noted that this is not the behavior on Linux.  However, before the
workshop started, Richard Offer and I were discussing at least one reason
why you might want to allow threads to work with their own credential and
capability sets: multi-threaded userland servers.  The example I started
out with was Coda and AFS servers, which make use of threads to handle
parallelism, and as the unit of service completion.  I.e., active threads
in Coda and AFS servers (except for housekeeping) generally represent a
single RPC in execution.  As a single server serves multiple clients in
the process, different threads are, in effect, acting with different
rights.  In Coda and AFS, the authorization issue doesn't come up as they
provide their own authorization and authentication modules.  However, for
distributed system services using the same authentication and
authorization schemes, such an environment would require the server
software to make use of multiple processes, or reduce parallelism.  If
threads could individually handle things such as capabilities, uid status,
etc, then it would be possible.

Casey correctly pointed out that this generally flies in opposition to the
POSIX model (which you describe accurately), which treats POSIX threads as
execution resources only, not as elements having their own authorization.
The current FreeBSD threading mechanism, by virtue of using only a single
real process, gives this behavior by default.  As FreeBSD moves towards
the scheduler activation model, keeping the credential set in the struct
proc would continue to provide the same semantics.  The argument Ted Ts'o
presented from the Linux side was that this would introduce an additional
spin lock to protect shared credential data, increasing the cost of
syscalls requiring authorization.  In the current 1:1 thread model, this
works fine, but in an m:n model, the expense comes back.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message