Re: [OT] Re: GGF's extensions to GSS in Public Comment

On Wed, Apr 07, 2004 at 12:58:00PM -0500, Douglas E. Engert wrote:
> Nicolas Williams wrote:
> > To further clarify this: NFS/AFS/DFS/CIFS/etc... generally use the
> > default credential (GSS_C_NO_CREDENTIAL), in fact, they have to because
> > the interfaces[1] through which an application uses filesystems do not
> > provide for an initiator name or credential input parameter.
> > 
> > Therefore the default_cred input parameter of GSS_Store_cred() provides
> > enough information for the implementation to decide whether or not to
> > make the given credentials available for use by remote file system
> > protocols.
> > 
> > [1]   Think of Unix system calls, such as open(2).
> 
> Ah, but applications like a web server may wish to have multiple credentials
> one for each sesion, and may wish to keep track of these, and to pass then
> on to child preocesses  or scripts where they ae used for access to 
> NFS/AFS/DFS/CIFS/etc ...

So?  They can do so just fine with GSS_Store_cred().  Just keep the
delegated credential handle around and GSS_Store_cred() it when
switching to the context of the user being impersonated.

> The web server itself may wish to access files using different sets of credentials
> too form the same process too.  

A process (or thread, depending on the platform) can only have one set
of default credentials for use when accessing the file system.  This is
true on every *nix platform and on Windows.

> So how do you propose that the application handle multiple delegated credentials?

Keep all of those delegated credential handles around and store them as
necessary when impersonating users.

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]