[OpenAFS-devel] PAGs/tokens/threads

[Chas Williams (CONTRACTOR)]

In message <Pine.LNX.4.64.0908071127490.25892@ossigeno.math.unifi.it>,Alberto Mancini writes:
>1. pags are associated to a session_type keyring i.e.
>      setpag (in src/afs/LINUX/osi_groups.c) assigns a keyring
>      in the struct_task (in signal->session_keyring, in my current kernel)
>      and stores a key of type afs_pag, named "_pag" in this keyring

yes

>2. the "real" pag is stored in the payload of the "_pag" key
>      (and in groups)

yes -- addtionally, the user is not allowed to examine the _pag key.
its contents are private and opaque.

>3. when a credential is required PagInCred (in src/afs/afs_osi_pag.c)
>      retrieve the pag from the keyrings using ``request_key``

yes

>4. ktc_SetTok (src/auth/ktc.c) through pioctl VIOCSETTOK associates
>      (I do not understand well how) a token to the "current" PAG
>      (current here, I assume, means the pag that is found via
>      the _pag key of the calling task)
>      I have some evidence of this, but I had no chance of finding
>      the right piece of code.

actually you probably want to look at src/afs/afs_osi_pag.c and the
getpag() and setpag() functions.  at somepoint a user ioctl is called and
this gets translated into a setpag() which creates the session keyrings.
getpag() is called by various parts of the afs client code to determine
your current pag.

>All the previous items let me to assume that:
>
>I cannot have a PAG associated to a thread (session keyrings
>are shared between threads) and, at the same time I cannot
>have different credentials associated to different threads of the same process 
>(tests for this exhibit a strange behavior but I think this is true).

pag is process authentication group.  so no, you should not expect
threads within the same process to be able to have different a different
pag.  as you discovered, the pag is on the session keyring, not the
thread keyring.

>On the other hand request_key (the one used in PagInCred) searches
>for keys in any keyring (in a fixed order, starting from the thread one)
>so if I store a key named "_pag" (as I did) in thread's keyring
>any thread can get a pag and, thus, can have (unshared) credentials.

possibly, but setpag() doesnt put the pag in the thread keyring. it
puts it in the session keyring.  so to get each thread into its 
own pag, you would atleast need a new setpag()?  or so i believe.

>If anything before happen to be true I have a question:
>what kind of interface can I provide to request a thread-pag ?
>In my local tests I hijaked syscall nr. 29 (left free) and it works
>but I have not idea of consequences.

perhaps not the best choice.  adding another ioctl on top of pioctl
is likely a better choice.  ideally i would say add an argument to
setpag() to indicate the scope of this ag (authentication group,
since it might be process associated anymore).

>Finally, I am not able to understand why pags are stored in groups too;
>any help ?

backwards compat for older programs (and users) that might look at
your group list to determine if you have a pag (for whatever reason).
obviously this will be somewhat confusing to a thread process.
this feature should go away since it exposes the pag value.