[OpenAFS] PAM problem with 1.4.4 and Linux
Derrick Brashear
shadow@gmail.com
Fri, 25 Jan 2008 12:41:23 -0500
------=_Part_1020_22566700.1201282883607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
>
> AFS typically provides session based PAGs. These allow you to
> seperate your AFS credentials into compartments that are based on a
> session identifier, rather than the UID (so, for instance, two
> processes both running as root may have different sets of AFS
> credentials). This requires that each 'session' have a unique
> identifier associated with it, that's unchangeable by the user and,
> ideally, that persists across changes in UID. Historically, this
> identifier was used by adding the user to two unused groups, whose
> IDs, when combined together would produce the unique number that
> identified that session (or PAG). The user would be added to these
> groups when setpag() was called, and a hook to the kernel's initgroups
> () command would ensure that the groups were copied across UID
> changes. In recent releases the two group IDs have been replaced by a
> single 32 bit group ID, but the rest of the principle is the same.
>
Due to complaints, in more modern linux (where 32 bit group ids are
supported) we attempt to use just a single group to represent a PAG. In
this case it will be one where the high byte is ascii 'A' (in code this is
((g0 >> 24) & 0xff) == 'A') for "Andrew", which is legacy.
The number of this group *is* the PAG number, unlike before where you took
the 2 groups and transmuted to a PAG number.
> This alternative mechanism relies on the 'keyring' feature present in
> recent Linux kernels. Keyrings provide a mechanism for associating
> arbitrary information securely with UIDs, processes, or (critically)
> sessions. This can be used for things like kernel credential caches,
> X509 key material, and the like. AFS uses it to hold the PAG
> identifier in a session keyring. This implements the session-based
> PAG behaviour, without requiring the same kernel hackery as the group
> code (it has the added advantage that users don't see random groups
> appearing when they view their group list)
>
Because we still try to maintain the groups by default, the group
information will be repopulated from the keyring-saved "PAG" when it appears
a setgroups() has wiped out the saved PAG.
Obviously this behavior will evolve as the kernel does, both as we are
precluded from doing what we did (not a big deal) and we have to adapt to
functionality which is exported to us or unexported from us (this is more
problematic).
------=_Part_1020_22566700.1201282883607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br></div>AFS typically provides session based PAGs. These allow you to<br>
seperate your AFS credentials into compartments that are based on a<br>session identifier, rather than the UID (so, for instance, two<br>processes both running as root may have different sets of AFS<br>credentials). This requires that each 'session' have a unique<br>
identifier associated with it, that's unchangeable by the user and,<br>ideally, that persists across changes in UID. Historically, this<br>identifier was used by adding the user to two unused groups, whose<br>IDs, when combined together would produce the unique number that<br>
identified that session (or PAG). The user would be added to these<br>groups when setpag() was called, and a hook to the kernel's initgroups<br>() command would ensure that the groups were copied across UID<br>changes. In recent releases the two group IDs have been replaced by a<br>
single 32 bit group ID, but the rest of the principle is the same.<br></blockquote><div><br>Due to complaints, in more modern linux (where 32 bit group ids are supported) we attempt to use just a single group to represent a PAG. In this case it will be one where the high byte is ascii 'A' (in code this is ((g0 >> 24) & 0xff) == 'A') for "Andrew", which is legacy.<br>
<br>The number of this group *is* the PAG number, unlike before where you took the 2 groups and transmuted to a PAG number.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>This alternative mechanism relies on the 'keyring' feature present in<br>recent Linux kernels. Keyrings provide a mechanism for associating<br>arbitrary information securely with UIDs, processes, or (critically)<br>
sessions. This can be used for things like kernel credential caches,<br>X509 key material, and the like. AFS uses it to hold the PAG<br>identifier in a session keyring. This implements the session-based<br>PAG behaviour, without requiring the same kernel hackery as the group<br>
code (it has the added advantage that users don't see random groups<br>appearing when they view their group list)<br></blockquote><div><br>Because we still try to maintain the groups by default, the group information will be repopulated from the keyring-saved "PAG" when it appears a setgroups() has wiped out the saved PAG.<br>
<br>Obviously this behavior will evolve as the kernel does, both as we are precluded from doing what we did (not a big deal) and we have to adapt to functionality which is exported to us or unexported from us (this is more problematic).<br>
<br></div></div><br>
------=_Part_1020_22566700.1201282883607--