[Top][All Lists]
[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