Nicolas Williams <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info