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

"Douglas E. Engert" <[email protected]> Wed, 07 Apr 2004 12:58:00 -0500
Newsgroups gmane.ietf.cat
Message-ID <[email protected]>

Nicolas Williams wrote:
> 
> On Tue, Apr 06, 2004 at 10:24:24PM -0500, Nicolas Williams wrote:
> > Actually, I don't think GSS_Store_cred()/GSS_Get/Set_current_cred_store()
> > should directly distinguish between credential stores of one kind
> > (user-land only) and another (kernerl+user-land).  I believe that the
> > default_cred parameter of GSS_Store_cred() provides enough of a hint to
> > the implementation as to what kind of store to use, where such a hint is
> > needed at all.
> 
> 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 ...

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

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

 
> 
> Cheers,
> 
> Nico
> --

-- 

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]