[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strategy of access
From: |
Greg A. Woods |
Subject: |
Re: Strategy of access |
Date: |
Mon, 9 Jul 2001 12:27:13 -0400 (EDT) |
[ 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>