Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Thursday, March 30, 2006 07:41:05 PM -0600 Nicolas Williams 
<Nicolas.Williams at Sun.COM> wrote:

> No, the kernel doesn't need PAGs for itself -- it upcalls to daemons
> that do (e.g., gssd(1M)) and which can use door_ucred(3DOOR) and friends
> to find out what the caller's PAG is.

Yes, it does.  PAG's are not sets of credentials; they are a form of 
process group.  Subsystems like NFS and AFS need to do things like keep 
track of which established connections are authenticated with whose 
credentials, and which cached access rights apply to which sets of 
credentials.  The latter is much more important than it may seem at first 
glance.  For a shared cache on a multi-user (multi-credential) system to be 
effective, the cache manager must know when it is allowed to use cached 
data to satisfy a request.




>> In any event, the API is easy.  The hard part is the _user_ interface...
>
> The user interface is easy: PAM (not quite in its present form) can
> handle all logon-time issues, while programs like kinit and keylogin can
> take care per-application associations in specific cases, and a generic
> command can list/break any/all associations.

It's not PAM, kinit, or keylogin that I'm worried about.  Creating 
completely new PAG's and new app data types to existing PAG's are both 
easy.  The hard part arrives when you want to create a new PAG which shares 
some application data with its parent.  And it's not just the splitting 
that's hard, but presenting the result to the user.



> Er, well, yes, but that is true even for the case where the process is
> creating a new PAG with this hack -- this isn't /proc's fault but the
> result of using supplementary groups to emulate first class PAGs.

Correct.