[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How to run :gserver: nonroot
Brandon Craig Rhodes
How to run :gserver: nonroot
03 Jul 2002 11:00:59 -0400
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
Description: Text Data
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech address@hidden
- How to run :gserver: nonroot,
Brandon Craig Rhodes <=