info-cvs
[Top][All Lists]
Advanced

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

RE: Security issues


From: Noel L Yap
Subject: RE: Security issues
Date: Tue, 10 Apr 2001 12:04:21 -0400

I can't go into details since my work never really made it into a production
development environment (and I haven't been using CVS in the last year), but
here it goes:

I'll assume knowledge of the basics like LockDir and setgid directories (it's in
the manual).

File system ACLs:
The manual pretty much goes over the permissions necessary in the repository:
   0. LockDir must be used.
   1. Those needing checkout privileges need:
      1. read and execute permissions on repository directories
      2. read permissions on archive files
      3. read, write, and execute permissions on LockDir directories
      4. read and write permissions on CVSROOT/history (and possibly some other
files) if it exists
   2. Those needing checkin privileges need:
      1.  write permissions on repository directories.

Once you understand this, using file system ACLs is a cinch.  For example:
     find $CVSROOT/some_module -type d | xargs setfacl -m g:another_group:rwx
# allow another_group to be able to checkin stuff into some_module

SSH (read the awesome O'Reilly SSH book for details since each SSH
product/version is different and it briefly mentions CVS configuration under
SSH):
1. Generate (within a local, non-exported directory) a key pair per user per
server.
2. Install the public key on the server.  At this point you can specify what
command is allowed per key pair.

Putting the two together, it should be pretty straight-forward to create one
read-only user on the CVS server that others can SSH to to checkout stuff from
the repo.  Those needing checkin privileges should have their own login to the
the CVS server.

Hope this helps,
Noel




address@hidden on 2001.04.10 11:02:36

To:   address@hidden, address@hidden
cc:   address@hidden
Subject:  RE: Security issues




Noel,

My group was recently enquiring into the possibility of implementing
some sort of CVS security. Would you mind giving some brief examples of
the kinds of things you can do with:

SSH
ACLs

I'm just looking for a little more detail than you provide below. This
will help me get my research pointed in the right direction. Thanks

Chuck



> Depending on the details of your needs, you can look into the
> following:
> 1. Use SSH.  This allows a secure (encrypted, authenticated,
> ...) login to the
> CVS server.  You can also limit users to executing CVS only.
> 2. Use file system ACLs.  This allows several different
> groups/users to have
> different permissions (to control checkin/checkout) within
> the repository.
> 3. Use separate repositories.  You've already mentioned this
> so I won't go into
> it further.
> 4. Use pserver.  I'm not too familiar with this approach but
> I've never run into
> anything the above doesn't cover.
>
> Noel
>
>
>
>
> address@hidden on 2001.04.10 08:44:55
>
> To:   address@hidden
> cc:   (bcc: Noel L Yap)
> Subject:  Security issues
>
>
>
>
>
> Hello list,
>
> now I have my CVS infrastructure growing bigger, several
> departments are using it, and aparently there is requirement
> for security. I need to restrict departments also there will be
> WebEdit interface running for more public people.
>
> Its not clear how to implement security inside CVS repository,
> by using accesslists? How to make CVS understand them?
> I'd like to keep singe CVS server.
> Also I'm not sure about possibility to have several repositories
> on one server, it looks like the easiest way to go though.
>
> Any experience doing this? Patches, scripts?
> Help greatly appreciated!
>
> -Nils J
>
>
>
>
>






This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.




reply via email to

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