Solaris Credentials Process Groups (CPGs)

CPGs are a new form of process grouping for Solaris.  As the name
indicates the membership of a process in a given CPG is tracked through
the process' credentials (cred_t in the kernel).

CPGs are the Solaris equivalent of AFS PAGs (Process Authentication
Groups) and Linux Kernel Keyrings.  CPGs are very similar to PAGs.

Properties of CPGs:

 - CPGs are typed
    - each CPG type has a name and a set of flags defining its semantics
    - new types can be registered in the global zone
    - there's a configurable maximum of CPG types that must be set early
      in the boot process

 - a process can be a member of zero or one CPG for each registered CPG type

 - CPG membership is inheritted across fork and exec
    - CPG membership must be changed explicitly

 - each CPG has a locally unique 64-bit CPG ID

 - each CPG can have a small amount of user-provided character data
   associated with it

 - arbitrary kernel modules can associate private data with any CPG
 - arbitrary kernel modules can be notified when the last reference to a
   CPG vanishes and/or when the user-provided CPG data changes

 - for each {CPG type, zone} there can be a daemon that registers a door
   through which it can be upcalled with messages indicating that a
   CPG's last reference has vanished and/or that CPG user data has been
   changed

Uses of CPGs:

 - AFS, NFS, CIFS, and other such kernel-based clients can associate
   Kerberos V, NTLM, and other credentials with CPGs instead of
   associating them with a single UID (as the Solaris NFS/RPCSEC_GSS
   client does).

   And they can associate arbitrary kernel-land state such as "NFSv4
   open owner IDs" with CPGs if such state is best tracked through open
   files' cred_t.

 - Physical devices associated with console seats can get semantics
   similar to session ID / /dev/tty by associating an actual device or
   devices with a virtualized device.  E.g., /dev/audio.


CPG types have semantics flags associated with them.  These flags allow
for:

 - controlling what processes can get/set CPG user data
 - controlling what processes can observe a process' CPGs' IDs
 - specifying whether new login sessions and su(1) sessions get a new
   CPG for the given CPG type or inherit the parent's
 - specifying whether the given CPG type is for device virtualization
   (see above)
 - etcetera; see main README.

Comparison to AFS PAGs:

 - AFS has a single PAG type
 - CPG system calls are richer, mostly so that the simple use cases can
   avoid knowledge of CPG IDs.


Comparison to Linux Kernel Keyrings:

 - Linux has a per-thread, per-process, per-session, per-user keyring
   facility.  There's no per-thread CPG facility -- only per-session,
   with single process sessions providing an equivalent to per-process
   functionality.  There's also no per-user CPG facility, but CPGs can
   be joined (subject to access controls and CPG type semantics), to
   emulate per-user keyrings.

 - The APIs are very different.


Architecture:

CPG membership is driven primarily by PAM modules and applications:

 - pam_unix_cred(5) causes a process' CPG memberships to change to new
   CPGs for any CPG types that have a semantics flag that indicates this
   should happen

    - there are two such semantics flags: one for logins and one for su.

 - login(1), gdm(1), ... cause a process' CPG memberships to change to
   new CPGs for any CPG types that are associated with console-type
   devices

 - pam_krb5(5) sets CPG user data for the process' CPG of type "krb5" to
   point to the ccache with the user's Kerberos V credentials.

 - svc:/system/cpg/krb5:default registers the "krb5" CPG type and runs a
   daemon to kdestroy Kerberos V credentials when the last reference to
   a CPG vanishes.


APIs:

 - For CPG syscalls see:

    - usr/src/head/cpgroup.h
    - usr/src/uts/common/sys/cpgroup.h

 - For API for kernel-land consumers see:

    - usr/src/uts/common/sys/cpgroup_kernel.h
    - usr/src/uts/common/sys/cred.h (for crgetcpg()/crsetcpg())