info-cvs
[Top][All Lists]
Advanced

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

Re: what's to stop a developer from nuking the repository?


From: xyzzy
Subject: Re: what's to stop a developer from nuking the repository?
Date: Sun, 29 Feb 2004 13:22:03 +0200
User-agent: KMail/1.5.4

On Tuesday 20 January 2004 11:46 am, Andrew Marlow wrote:
> "Rhodes, Phillip C." <address@hidden> writes:
> >I am nervous that all my cvs archives are owned by a group that all of
> >our developers are a member of.
> >That is, any developer with a unix account (all of them) can nuke the
> >archives.
> >
> >Besides backups....  any thoughts on this?  Sorry, I am new to cvs...
>
> I use cvs over ssh and the machine is completely locked down. The only
> access other than via cvs+ssh is a restricted shell login which does not
> include access to the rm command and several other potentially dangerous
> commands). The restricted shell also places you in a chroot prison. Seems
> to work.
>
> Regards,
>
> Andrew Marlow
 -- snip sig --

I have this problem also.  It's already happened, and I had to restore with 
backups.  I need to restrict the /cvs directory so the only access to it is 
via CVS, perhaps not even read access.

The problem is that the cvs directory is on the same machine as all the other 
server stuff including user's server home directories.  Thus, a user can 
access the server via a simple 'ssh', then do 'cd /cvs' and have free rein 
due to the permissions set below.

1. How do you enforce a restricted shell with a chroot prison?  A hacked 
version of ssh?

2. How do I muck with the permissions so that developers can't even read, much 
less write to the cvs directory, but not damage regular cvs access?

That is, the system-wide passwd file has a user named "cvsaccess" ("not his 
real name" :-)

Then, /etc/group has a group named 'cvs' with cvsaccess as well as all other 
users that need access to CVS attached to that group.

'cvsaccess' is also listed in the CVSROOT/writers file.

All objects in the /cvs directory are owned by cvsaccess/cvs with all files 
having 444 permissions, the directories having 775 permissions.  This is a 
mess.  Since the same user that accesses the main server via ssh has write 
permissions due to membership in the 'cvs' group, this allows nuking of the 
repository files.  How do I fix this?

Also, would it help if I enforced a provision that all users access cvs 
using :ext: only via ssh?  How would this work with WinCVS users?

If I need to open up another thread on this, please advise.  I believe I am 
on-topic here, just expanding the parent topic a bit.





reply via email to

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