Re: Strategy of access

[Greg A. Woods]

[ On Monday, July 9, 2001 at 12:25:53 (+0200), address@hidden wrote: ]
> Subject: Strategy of access
>
> The main strategy is to control users access to selected projects'
> subdirectories.  I use one repository for all projects.  CVS server is
> installed on Linux and dedicated only to use in intranet so advanced
> security considerations are not necessary.  All subdirectories have set up
> setgid (I read about problems with it on Linux but actually it works on
> RedHat 6.2).  Each subdirectory which is entry to project have set own
> group as in this example:
>      permissions    group          dir
>      drwxrws---  users       CVSROOT
>      drwxrws---  project_a   project_a
>      drwxrws---  project_b   project_b
>      drwxrws---  project_c   project_c
> 
> Each CVS user have unix account on server where CVS is installed and his
> primary group is 'users' (read-write access to some administrative files in
> CVSROOT).  User that can access given project is added to proper group -
> then that user can fully operate on this subtree.  So user (1) can access
> or (2) cannot access project in repository.

I'm not sure how strict you want to implement your policy, but there are
a huge number of potential ways a user can access other projects if they
have access to the administrative files.  Most of these ways are eaisly
spotted in changes to the administrative files but not all of them.....

You might want instead to set up a repository administrator group and
only give membership in it to trusted users:

     permissions group       dir
     drwxrwsr-x  cvsadmin    CVSROOT
     drwxrws---  project_a   project_a
     drwxrws---  project_b   project_b
     drwxrws---  project_c   project_c

You might want to do this anyway even if you don't want a strict
enforcement (i.e. still create an optional "cvsadmin" group, but for now
just give everyone membership in it) because it makes it much easier to
enforce a more strict interpretation of the policy later.

>  But what about (3) read-only
> access to project (kind of auditing)?

For this purpose you'll need to make the project directories globally
readable and searchable, and tell CVS to put its locks in some other
place were all users can write

     permissions group       dir
     drwxrwsr-x  cvsadmin    CVSROOT
     drwxrwsr-x  project_a   project_a
     drwxrwsr-x  project_b   project_b
     drwxrwsr-x  project_c   project_c

Then look for the node "The CVSROOT/config configuration file" in the
manual and read up on the "LockDir" option.  The lock directory would
need to be writable by the group "users" in your example.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>