Re: a gserver patch

[Mei-Hui Su]

Hi,

>> diff -u -r cvs/configure cvs-1.11/configure
>> --- cvs/configure       Thu Apr 26 13:54:31 2001
>> +++ cvs-1.11/configure  Tue Aug  1 09:13:25 2000
>
>You shouldn't change the configure file.  You should change configure.in and 
>run a
>utoconf to generate confiugre.

  I did change the configure.in and generated the configure via autoconf.
The diff started on the top dir and so it also made the diff file for configure.


>> -#ifdef HAVE_KERBEROS
>>  /* We use Kerberos 5 routines to map the GSSAPI credential to a user
>>     name.  */
>>  #include <krb5.h>
>> -#endif
>> -
>> -#ifdef HAVE_GSI
>> -/* We use GSI's gridmap routines to map the GSSAPI credential to a user
>> -   name.  */
>> -#include <globus_gss_assist.h>
>> -#endif
>
>Shouldn't you have been able to use GSSAPI to rewrite the client and server 
>both i
>n such a way that they didn't care
>what sort of authentication mechanism was hiding behind the GSSAPI 
>(Kerberos/GSI/w
>hatever)?  Why didn't you?

 As the code stands right now, the client does not care which flavor of GSSAPI
is underneath it. Most of the server code does not care either except the 
mapping to a local user id is outside of GSSAPI. For example, in original 
server code, the access mapping is tied directly to krb5 and in the code 
with a note,

    /* FIXME: Use Kerberos v5 specific code to authenticate to a user.
       We could instead use an authentication to access mapping.  */

 Even if I layer in the SASL, the question of how to map an authenticated id
to a local user is still there..

mei