info-cvs
[Top][All Lists]
Advanced

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

Re: common vs confidential development parts


From: Paul Sander
Subject: Re: common vs confidential development parts
Date: Fri, 21 Dec 2001 11:18:32 -0800

I had a similar problem once, and I couldn't solve it without modifying
CVS.  Our solution was to use CVS in local mode (i.e. use NFS for network
access), and set permissions on the repository so that members of the A
group had read/write access to module A, members of the B group had read/write
access to module B, modules A and B were closed to the world, and the C
module was open to the world (or rather to a C group that was the union of
the A and B groups).

The part that needed modification to CVS was that we had a table that
mapped modules to groups.  CVS looked up the module name to find the
required group and then checked permissions on all of the ancestor
directories of the root of the user's sandbox until it found one that
was owned by the user, had its group ownership set according to the module,
and its mode set at least as restrictive as 0770.  This same check was put
on update and commit.

This mechanism didn't prevent users from checking out confidential modules
and then opening up permissions inappropriately, but it did make it just
inconvenient enough to show intent to give improper access.

A better solution would be to hack the modules database to specify a
CVSROOT in a module inclusion, and then use server mode with access controls
(such as ssh) to allow appropriate people on appropriate machines.  This
requires involving your IT department to partition machines among groups
and strict controls over the user accounts on those machines.

--- Forwarded mail from address@hidden

anybody ever tried the following? Or any hints about it?

We need to team to collaborate around the same basis but to develop
separate (and confidential) add-ons.

So, in the src/ directory we have stuff like
A-module1
A-module2
A-module3
...
B-module1
B-module2
B-module3
...
C-module1
C-module2
...

The constraints are
A modules should only be accessible to team A
B modules should only be accessible to team B
C modules should be accessible to all

But how can we avoid the hassle of having to cvs-handle every module 
individually...
What would in particular be very annoying for releases...

--- End of forwarded message from address@hidden




reply via email to

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