On Aug 29, 2007, at 9:46 AM, Howard Chu wrote:
And with it it has the same ownership issue as a regular ccache
file. Also, access control is limited to what inheritance provides.
Could you summarize these ownership concerns again, or point me at
an archived posting that enumerates these issues? I've missed some
context somewhere.
The context is that some of us would like to solve the AFS PAG
(Process Authentication Group) problem the same way we solve the
secure credential cache problem. PAGs have better semantics than any
extant Kerberos ccache implementation.
As such the historical contextual reference would be some old CMU
paper that I won't take the time to find (right now anyway). The
paper IMO spends too much time on the "funny group number"
implementation of PAGs, and not enough on the user-level semantics.
(As Russ said, the "funny group number" implementation worked
surprisingly well until about 5-10 years ago when Linus Torvalds and
Apple, Inc., and maybe other people decided that the kernel
modifications needed to muck around with group numbers were bad.)
This has led to some unfortunate erosion in people's expectations
from AFS capabilities.
From an implementation standpoint, PAGs are efficiently searchable
by a kernel filesystem module in order to match credentials to
callers. Since they're stored in the kernel there are syscalls to
get/set/erase entries from user space. The kernel module gets to
implement the semantics that seem best, and I think the semantics
they defined are pretty good. Kerberos doesn't implement any kernel
modules, and therefore has compromised their ccache scoping semantics
(and associated security) to fit the available userland mechanisms.
The interesting thing about this thread, to me, is that we seem to
have people interested in pushing the envelope, and using new
userland capabilities to get better scoping semantics.
From a user's perspective, a PAG is like a terminal login session
with two exceptions. First it's "secure"; you can't break into and
access anything from another session (even with the same UID).
Second, you can create new ones on the fly; on AFS this is done by
running "pagsh" and doing work under the new shell.
PAGs are inherited by sub-processes, including set-uid-root ones like
lp (which is handy for printing files that live in AFS filespace).
There is no set-pag-id capability. Once you're in a PAG the only
ways to get out are to create a new, empty PAG or to terminate the
process (reverting to the parent's PAG as part of returning control
to the parent).
A new PAG has no credentials. You can test a program inside a new
PAG without worrying that it might modify your files.
Credentials added to a new PAG do not "leak" to other processes on
the machine. You can create a terminal window with administrative
credentials in its new PAG without worrying that a process run
elsewhere might acquire the ability to do more than you intended.
When we talk to OS people about PAGs we usually get hung up on the
"secure storage" issues, and don't necessarily get the inheritance/
scoping problem solved. The Linux keyring implementation had issues
along those lines, but I think (hope) that the implementation at
least allowed PAG semantics to be implemented, even if it provided a
bunch of other unimportant options.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
