"Brian Huddleston" <[EMAIL PROTECTED]> writes:
> >[... pserver over ssh ...]
>
> The advantage of this approach is that you can set developers up as CVS
> users as opposed
> to real users of your system. While you might trust people to have
> repository access you might
> not want to trust them shell access to your machine.
IMHO that should be an option for the non-pserver authentication modes
as well.
horio shoichi <[EMAIL PROTECTED]> writes:
> For kerberos, there is a problem with krb_kntoln: it does not understand
> cross realm issue, so doesn't successfully map remote principal name to
> the local one. I wrote a small mapping program to work around this problem.
> If your plan is to use gserver, the problem you encountered can be very
> much the same sort.
Kerberos 4 and 5 as shipped by MIT both have hooks for changing the
mapping from principal name to local account name. In version 4, at
least, I don't think it was well documented, and may have been a
non-default compile-time option.
But I think SASL has the better approach -- send an account name
separate from the authentication information, and let the server side
decide whether to grant you access to the account. (Where "account"
may or may not correspond to "UNIX user id", etc.; it could just be an
arbitrary name.)
I suggested using SASL for CVS a long time ago, but the one or two
extra round trips during setup were met with more than a little
resistance. (Far more than made sense, IMHO.) It would have the
benefit of allowing future authentication methods to be added without
further impacting the CVS protocol spec, and if the SASL code were
imported from elsewhere, presumably without changing the CVS code
base. (GSSAPI has some of the same benefits, but doesn't
automatically add the account-name component; that's left to the
application protocol. It also doesn't address the authorization
issues, so that's left to the application too, which has to do it with
some awareness of the authentication mechanism used.)
Ken
