BTW, Solaris tasks approach the semantics of PAGs. See settaskid(2).
They're not quite what you want for two reasons: a) they're already in
use for something else, so you don't know that someone isn't going to
change a process' taskid without doing the AFS thing to keep credentials
associated with it, and b) taskid_t is an id_t, which is a signed 32-bit
integer type, and that's just too small for things that can be generated
on demand.
Given PAGs one could layer a method of associating network credentials
for multiple mechanisms (instead of just Kerberos, as OpenAFS does) with
sessions. Imagine a daemon whose job is to track {PAG, mech, cred_ref}
tuples; it's job is to allow callers to register credential associations
with their PAGs and to let callers find them again. Then an API to go
with it.
A while back I designed such an API, which I called the generic
credential store API (GCS-API) that provides a way to get a handle to
the current credential store for a given thread, process, session or
user, a way to associate a credential store handle with a thread,
process, session or user, a way to list the credentials references in a
store, and so on.
If you'd like I could send you a man page I wrote for it.
Nico
--
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
