[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to run :gserver: nonroot

From: Brandon Craig Rhodes
Subject: How to run :gserver: nonroot
Date: 03 Jul 2002 11:00:59 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

We wanted to avoid creating dozens of user accounts on our secure CVS
server for our developers.  This would normally be accomplished by
using the :pserver: mechanism with a CVS `passwd' that mapped them all
to a single user, like:


But the plaintext password transmission of :pserver: was inadequate
for our needs, so :gserver: seemed our obvious choice - but then there
would be no way to map users to the singe `cvs' account (because the
:gserver: protocol (unlike :pserver:) does not know which repository
the user is going to use).  The CVS server would also need to run as
root, which was undesirable from the point of view of security.

Our solution was simple:

  (a) We changed the :gserver: method so that, instead of trying to
  setuid(2) to the user, it just compares his name to the `readers'
  and `writers' files when he tries to access a repository.  This
  means that the server can run as non-root and, since it will just
  keep running as its original user, we do not need to create a Unix
  account on the machine for each developer.

  (b) The current `readers' and `writers' scheme has an insecure
  default of permitting access, but most of our Kerberos users are not
  developers.  We therefore change (and in the process simplify) the
  meanings of these files: `writers' lists who can both read and
  write; `readers' lists who else can only read; and users listed in
  neither are denied access.

  (c) Since the /etc/krb5.keytab file is usually only readable by
  root, but our CVS server now runs as `cvs', we added a `-k keyfile'
  option to CVS with which an alternate keyfile can be specified.

A patch accomplishing the above is at the bottom of this mail.

After recompiling CVS (making sure its uses gssapi) and reinstalling,
create a user for CVS, which we called `cvs'; create a directory for
your repositories which can only be read and written by this user;
create a keytab file readable only by this user with Kerberos keys for
the principal cvs/HOSTNAME; and add the following to /etc/inetd.conf:

        cvspserver stream tcp nowait cvs /usr/local/etc/tcpd SCRIPT

where `cvspserver' corresponds to an appropriate port in /etc/services
and SCRIPT is a shell script that looks like:

        cvs -k KEYTAB -f --allow-root=REPOSITORY_ROOT pserver

(We used a script to keep the command line in inetd.conf simple.)
Substitute the path to the keytab file you created for KEYTAB, and the
directory where your repositories will reside for REPOSITORY_ROOT.

Now to lock down your permissions: add `SystemAuth=no' to your
CVSROOT/config and create an empty CVSROOT/passwd file, which together
disable normal :pserver: access; then create a `readers' and `writers'
file (both are now required) listing the users to whom you wish to
grant access through :gserver:.

We welcome comments on our code and technique, and feedback about
whether others find this useful or - with further modification - might
find it useful in the future.

(Note that cvs-1.11.2 does not support :gserver: without an additional
patch - either use an earlier version, or the current version from the
development tree.)

Attachment: cvs-nonroot-kerberos.patch
Description: Text Data

Brandon Craig Rhodes               
Georgia Tech                                            address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]