info-cvs
[Top][All Lists]
Advanced

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

Re: symbolically linked module root


From: Kevin Layer
Subject: Re: symbolically linked module root
Date: Thu, 30 Oct 2003 09:53:39 -0800

Mark D. Baushke <address@hidden> wrote:

>> Kevin Layer <address@hidden> writes:
>> 
>> > I want to give a contractor access to one module in my repository.
>> > Let's say I have this situation:
>> > 
>> > cvsroot/
>> >   CVSROOT
>> >   moda
>> >   modb
>> >   modc
>> >   ...
>> > 
>> > Because I have a large number of checkouts of `modc', I can't just
>> > move it to a new repository.  I'm thinking of creating a new
>> > repository directory like this:
>> > 
>> > cvsroot2/
>> >   CVSROOT -> ../cvsroot/CVSROOT
>> >   modc -> ../cvsroot/modc
>> > 
>> > and having them use cvsroot2 as their repository.
>> > 
>> > Is this safe?
>> 
>> Not really... cvs does not really understand symbolic links and is
>> potentially going to give you problems with locking the directories
>> in that manner. 

We use cvs in server mode, and if all the symlinks are links to files
on the same filesystem, I don't see why that wouldn't work.  If
course, if NFS was involved, I'd completely agree with you.

>> It might work as you have outlined if you are NOT
>> using the LockDir directive in CVSROOT/admin, but it is not clear
>> to me how you could stop the contractor from getting access to cvsroot/
>> in the first place.

Actually, I imagine a slightly different scenario:

cvsroot/
  CVSROOT ../cvsroot2/CVSROOT
  ...
  modc -> ../cvsroot2/modc

cvsroot2/
  CVSROOT
  modc

and the contractor is chroot'd into cvsroot2, and the only command
they can run is `cvs'.

>> 
>> > Is there a better way to do what I want to do?
>> 
>> a) Hire trustworthy contractors and give them full access to your
>>    sources.

Essentially Security Through Prayer (TM).  You know that the vast
majority of security breaches are from insiders, right?

>> b) Use UNIX permissions such that he is in a group that may only
>>    read/write the modc tree.

I thought of this.  The problem with it is that is tends to degenerate
over time.  Well meaning people change the setup, etc, which makes the
situation less secure.

>> c) Have someone else checkout sources for the contractor and then
>>    have the contractor submit patches to a designated set of users
>>    to have them commit the changes into the tree.

This is what we're currently doing.  It's labor intensive.

>> d) Move the modc module to a separate repository and let your own
>>    people share the pain of needing to use multiple repositories
>>    to do their own work.

Yes, I already mentioned not wanting to do this, but it's a
possibility.  If we change, I'm thinking this is the front runner.

Kevin




reply via email to

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