[Top][All Lists]

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

Re: Problem with admin privileges

From: Julian Opificius
Subject: Re: Problem with admin privileges
Date: Sat, 02 Jul 2005 14:27:44 -0500
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Mark D. Baushke wrote:
Hash: SHA1

Julian Opificius <address@hidden> writes:

Larry Jones wrote:

Julian Opificius writes:

I'm not quite sure what you mean by "mapping" users.

Using the third field of the CVSROOT/passwd file to have the server
as some user other than the actual user.

Yep, that's what I am/was doing.

I want each user to have his own login to the system, and I want to
control access to CVS repositories on a per-user basis, which is
why I use pserver.

There's no need to use pserver for that.  In fact, pserver is a giant
security hole that is best avoided.  Since you're giving your users ssh
access to the server anyway, the best thing for you to do is to use
:ext: mode with ssh rather than rsh (which should be the default if
you're running CVS 1.12).  Each user logs in as themselves and you can
then use ordinary file permissions to control who has access to
what. See the manual for details:
-Larry Jones

I have one more issue that affects my choice that I should have
mentioned earlier. We are working in an FAA-regulated environment, and
my CVS respository must be secure, in that nobody can impair the
lifecycle data, and all accesses must be documented and controlled,
i.e.e all accesses must be via the cvs server. This is why I chose
pserver in the first place.

How can I maintain this level of integrity without pserver: keeping
the repository itself inaccessible, while allowing write access
through cvs?

Using ssh in a restricted execution mode in general and for restricted
execution of CVS is discussed in many places.

I suggest you may find more reading useful... try these documents:

You may also find other documentions via your favorite search engine.

Thanks for this input!

The problem is that each of these articles achieve their intended results by restricting commands to "cvs". I don't want to do that: my CVS users are my engineering department members with legitimate logins. It's only access to the CVS repositories that I have to control. PServer through ssh does exactly what I want in that regard.

I have solved most of my admin problem by running admin users as their themselves using $CVSROOT/CVSROOT/passwd entries like this:
rather than as the global cvs user:

The only problem now is that if a cvsadmin user introduces a directory into the cvs repository using "add", the directory is owned by him, not by the global cvs user, and nobody else can check into/out of that directory.

How do I automatically force new directories created by the cvs server to be owned by the global cvs user, rather than the effective user? Maybe there is a Linux feature - something akin to setuid - that operates on the top level repository directory?


reply via email to

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