> > 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).
