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]