>>>>> "Rob" == Rob <[EMAIL PROTECTED]> writes:
>> Indeed, there was another issue involved: There appears to
>> exist quite a large fraction in the CVS community which
>> believes that pserver access is inherently unsave because any
>> write access to the cvsroot directory allows root access to the
>> system. While, sadly enough, this is true, there is a dispute
>> about how much CVS should care about security (which appears to
>> be quite a big chunk of work). There are people who say that
>> security should be granted by other means, e.g. ssh. It seems
>> to me that this implies the tendency not to support pserver
>> development.
> Excellent... this is exactly what I wanted to know. I have
> (what I think are, at least) some good ideas of how to make the
> pserver more secure, and would like to implement some of them
> (first and foremost, is getting the server to run as a user
> 'cvs' instead of root). I am currently trying to search the
> egroups.com list for the thread you mentioned, but I am not
> having much luck. Any hints on times or subjects of the thread?
There was a good deal of traffic with --allow-list in subject.
>> To me, the open problem remains: 1) I want to set up a
>> dedicated CVS server for approximately 20 repositories managed
>> by possibly different people. 2) The repository managers ( as
>> myself too) do not have root access, but they want to control
>> to a larger or smaller extend the access of other people
>> (inside and outside of our domain) to their repositories
>> without interfering with the sysadmin. Ideally in a fine
>> grained way -- on a per user and per directory base. 3) I
>> would like to run jCVS as a GUI for the vanilla user. This is
>> inherently bound to pserver.
> The first and third issues are my main concerns. I would like
> to see parts of your #2 happen, but in the mean time, I am one
> of the admins for my department, so I can work around this in
> the short term. I actually have jCVS up and running correctly
> for a number of my users.
It is possible to configure CVS repositories that don't need root
access. root access is only needed to setup the --allow-root part.
Once the repository is created root access is not needed. I use the
userid mapping capability of $CVSROOT/CVSROOT/passwd.
>> I am still thinking about the right compromise. It would be
>> good to have a flexible and at the same time secure CVS setup
>> as one aim of code development.
> My goals are to: - make all of the admin actions that normally
> require access to the local file system (like removing empty
> directories, or cleaning up cruft that will never be needed)
> available remotely - make the server run as a non-privileged
> user (not as root) - change the authentication mechanism to use
> some type of One time pad (skey?) - have some sort of token
> system for the login process so that your login expires after a
> certain amount of time, to prevent lots of stale entries in
> $HOME/.cvspass - make running more than one repository off the
> same daemon/machine simpler
Pserver only spends a short amount of time running as root. If you
don't run as root, setuid() won't work. I have modified my local
version of CVS. After authenticating, It will stop if the user is
still root. This catches mappings to root in passwd too.
As far as expiring the .cvspass entries, I have not figured that one
out. It would require some modifications to the pserver protocall;
related to the initial authenication. The server could maintain some
kind of key that's only valid for a given period of time. However,
this begins to complicate pserver. Others have created .logout scripts
that remove .cvspass when they logout. the .cvspass file should have
permissions of 700 (rw-------). This keeps prying eyes out under unix.
my $.02 worth,
Mike Sutton | public class
SAIC | software_failure : management_failure
Beavercreek, OH |
[EMAIL PROTECTED] | These are MY opinions, not SAIC's
