[OpenAFS] Hardware Grants from Sun

[Marcus Watts]

Nicolas Williams <Nicolas.Williams@sun.com> writes:
...
> We've waffled internally about how best to deal with PAGs.  Partly we
> (well, I) worry that the way PAGs work PAGs are too closely linked to a
> single network authentication mechanism and credentials, therefore it's
> not general enough for us since we'd want a scheme that works with
> multiple security mechanisms.
...

Going the other way from what Nico proposes, why not have a very
general per-module way for modules to add resources per-process?

There's really only a few points where the "generic" environment
needs to interact with the module:
	/1/ fork
		increment reference count to resource?
		copy resource?
		break attachment to resource?
			)) let the module choose here.
	/2/ exit
	/3/ module unload time
	/4/ 	ideally, also thread & exec logic...
		?? setsid ??
if the module can associate data with a process, retrieve it on
demand, & handle clone/fork issues - then it can implement pags
just as they exist today.  It could also
implement any other interesting structure of its choosing.
This means any policy issues can be sorted out entirely by the module and
do not need to be a concern of the enclosing os environment.
Then other modules could experiment with different choices.
There are probably already other kinds of data in the kernel,
such as sysv ipc keys, that could be similarly described.

The generic mechanism here could be something like the userland
"pthread_key_create" and "pthread_setspecific" -- or the pam_get_item
& pam_set_item calls.  The least requirement is that the kernel
provide hooks for modules to be invoked at the appropriate places.
A more fully featured mechanism would provide a way to actually
store per-process keys or data, perhaps to make this per-thread,
and perhaps to interact with other interesting per-"session" kernel
semantics.

					-Marcus Watts