[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the unprivileged gserver patch
From: |
Brandon Craig Rhodes |
Subject: |
the unprivileged gserver patch |
Date: |
19 Sep 2002 17:52:11 -0400 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
This edition of my unprivileged server patch is the first one which
might actually work, marking a sort of milestone in our progress with
it here. It should be applied to the stock 1.11.2 distribution.
This patch enhances security for sites using the :gserver: method.
Particularly important to us are that: the server can now run as a
user (we made a `cvs' account for it here) instead of being root; CVS
users need only exist in the Kerberos database rather than being given
accounts on the CVS machine; and the `readers' and `writers' files not
only have far more sensible and obvious meanings, but feature a secure
default - they deny access to users listed in neither file (our campus
Kerberos database has something like thirty thousand entries, most of
whom are not involved in our project).
The specific enhancements included in this patch:
Users need only present a valid Kerberos ticket, they need not have
an account on the machine where the server is running.
The LOGNAME, USER, and CVS_USER environment variables are set to
the user whom Kerberos authenticates, so that scripts (commitinfo
scripts in particular) can correctly determine user identity.
Access rules: users listed in `writers' can both read and write;
users listed in `readers' can read; other users are denied access.
The error message denying access now states correctly whether you
are being denied "read" or "write" access depending on the command.
The server supports a `-k keytab' option to specify an alternate
Kerberos keytab file (our system one is readable by root only).
Since all email sent through `loginfo' now comes from the server
account, not from the user doing the commit, we added a line to the
log message stating which user is committing.
When we set up a server we: create a `cvs' account; create a Kerberos
principal for the service which we place in its own ~/keytab file;
initialize its repository (such as ~/repository); and arrange for
inetd to run:
cvs -k /.../keytab -f --allow-root=/.../repository pserver
as the user `cvs' when connections arrive.
Comments, contributions, and corrections welcome as always.
Thanks to Mark Visser <address@hidden> for helping us test.
unpriv-gserver-2002-09-19.patch
Description: Text Data
--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech address@hidden
- the unprivileged gserver patch,
Brandon Craig Rhodes <=