RE: Silly question about CVS and permissions

[Michaelis, Daniel]

Todd,

Thanks for the answers.

Regarding your comments, my intent is less to provide a "secure" environment
(we don't expose cvs outside the internal network), and I'm not terribly
worried about malicious destruction of data; I'm much more concerned with
the occasional "fat-fingered" mistake that folks make, or the mistaken
impression that they're on server A when, in fact they're on server B.  As
such, it's probably not worth the administrative hassle to restrict ssh (but
you're right; that's probably the best solution for a secure environment).

I'm not using pserver; I had mistakenly assumed that someone had mucked with
permissions on the cvs executable, because I mistakenly assumed that it
would take advantage of the setuid capability in a Unix environment, and
manage reading/writing on its own.  

The errors that I was getting were undoubtedly due to the setuid that I
used; when I revoked that, the problems disappeared.  I'm not sure why those
messages would be generated, but a number of posts indicate that there are
problems with setuid on the cvs executable.

Again, thanks for the input.

Dan Michaelis
 
Database Administrator/Developer
eOriginal
351 West Camden Street
Suite 800
Baltimore, MD 21201
 
410.625.5187 (phone)
410.659.9799 (fax)
 

-----Original Message-----
From: Todd Denniston [mailto:address@hidden 
Sent: Monday, April 18, 2005 3:15 PM
To: Michaelis, Daniel
Cc: 'address@hidden'
Subject: Re: Silly question about CVS and permissions

Michaelis, Daniel writes:
> 
> This is a multi-part message in MIME format.Please do not send MIME and/or
HTML encrypted messages to the list.
Plain text only, PLEASE!
>
<SNIP>
> there doesn't seem to be anything that prevents User1 
> from going into the ProjectDir1/bin directory and 
> removing file2 (which is owned by User2). 
<SNIP>
1) the users should not be working directly in the repository except in very
rare cases and should be approved for doing the work there, this should be a
stated company policy.
2) if you are using ssh, ssh can be configured to limit the commands allowed
to be ran by the user(except if the user figures out a hole in the programs
they are allowed to run, see the next item).
3) if the user is violating company policy, whether or not that involves
breaking another program, discipline appropriately.

<SNIP>
> I've kludged a solution, which is to set the setuid 
> flag on the cvs executable, but I've seen a number 
> of posts that indicate that isn't a wise move, and 
<SNIP>
This sounds like a pserver problem, and if you are worried about security,
you don't use pserver.

<SNIP>
> 1.Is it the design of CVS that any user that needs 
> to check in/out files must have read/write 
> permission on all of the directories into which 
> he/she can check in files 
> (meaning that he/she has remove permission 
> at the O/S level within these directories)? If so, I'll 
> stop trying to solve this problem. 

Yes.

>   2.Are my (CVS/Repository missing) messages related 
> to the setuid that I've done on the cvs executable? 

Unknown, which method are you using to login? 
what does `echo $CVSROOT` return or what are you passing after `cvs -d`?

>   3.If the previous is true, is that because setuid is
>  truly not supported for the cvs executable, or is it 
> something that I've misconfigured? 

>   4.If there is a way to prevent destruction of files, 
> and it is not through setuid, what is the method by 
> which I would accomplish this? 

The users should only be accessing the repository through cvs.
The company should make a written policy that the users will only access the
repository through cvs.
The users should be trained that they should only access the repository
through cvs, and that it is company policy.
The company should only (I hope this is common sense) higher and retain
employees who can understand and follow company policies regarding
destruction of company property(code base in this case).

technology can help a little here, keep the cvs repository on a machine
which has been setup for ssh access and has ssh access limited to running
cvs, for all but administrative people.
 

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter