Solaris ssh pam_krb

[Nicolas Williams]

On Thu, Mar 30, 2006 at 09:12:50PM -0500, Jeffrey Hutzelman wrote:
> 
> 
> 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.

I didn't mean that the kernel doesn't track PAGs, just that it (for the
uses of PAGs I have in mind) doesn't actually care what they are because
other entities -- instances of daemons such as gssd -- do that for it.

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

Yes, and the way you get this is by having these operations:

 - new PAG, copy all associations with the old one
 - new PAG, don't copy...
 - get association for application <app>, PAG <pag_t>
 - set association for application <app>, PAG <pag_t> to <value>
 - list associations for PAG <pag_t>

(It doesn't have to be quite like this; you could have a "get handle to
all associations for this PAG" operation and "set this PAG's association
handle" to do the copy, and so on, but I digress.)

UIs don't need to provide the "set association..." operation.  The API
has to provide all of them.

Nico
--