I am not a CVS wizard, but I am pretty sure that my fixes to some GSSAPI
problems I encountered recently will be of interest to others, since they
seem so reasonable. :-)
All of this is relative to CVS 1.10.8 on FreeBSD 4-STABLE.
problem 1:
The GSSAPI code (gserver_authenticate_connection in src/server.c) does a
krb5_kuserok() and a setuid() on the basis of the Unix username that it
extracts from the Kerberos principal name. This creates an unnecessary
coupling between Kerberos user management and Unix user management; i.e.,
every Kerberos user has to have an account on the CVS server. It also
requires the CVS server to be run as root.
fix 1:
Run the cvs server as the user who owns the repository. Do the
krb5_kuserok() on that user. Do not setuid(), but just set CVS_Username
to the name of the Kerberos principal.
Effects: a principal can only access the repository if he is listed in
~cvsuser/.k5login. (This is krb5_kuserok's role.) All changes are logged
with the Kerberos realm included, although you must substitute % for @ to
avoid breaking RCS. This allows the GSSAPI code to be used with multiple
realms, since there will be no confusion between commits from mab%LATHIAN
and mab%RESEARCH.ATT.COM. Users do not need to have accounts on the CVS
server.
problems with the fix:
There are certainly people used to the existing behavior. So perhaps this
should be made a command-line option? If the general idea seems correct
to people, I will be happy to integrate it in the way that seems best, and
submit a proper patch. It's a very small change.
problem 2:
When Kerberos authentication fails on the server side for any reason, the
client bombs out with an ugly assertion failure:
assertion "need <= sizeof buf" failed: file "client.c", line 4158
Abort trap (core dumped)
fix 2:
I am not really Kerberos-savvy enough to see what is going on here
easily. If there is any trouble reproducing it please let me know. A
good way to get the above error is to leave the cvs principal out of the
CVS server's keytab.
problem 3:
AFAICT there is no mechanism to tell the CVS server where its keytab is.
This means that the standard keytab, /etc/krb5.keytab, needs to be
readable to the user that the CVS server runs as. Since the existing
GSSAPI stuff wants to run as root this is not a problem, but in my scheme
one would want to have a separate keytab.
fix 3:
Again somebody with more Kerberos knowledge will need to do this.
