[Top][All Lists]

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

Re: What could go wrong with this scenario?

From: Philip Lijnzaad
Subject: Re: What could go wrong with this scenario?
Date: 14 Nov 2001 18:42:59 +0000

>> A good description from the list archive:

>  From this message...

> ...probably need to set the set-group-id (SGID) bit on the directories
> in your repository (chmod g+s) -- that usually makes newly-created files
> and directories get their gid from the parent directory instead of from
> the creating process on systems where that doesn't happen by default...

> - usually?

yes, not all Unixen actually do this; it is a BSD thing, and used not to be
available everywhere. IOW, check if it works. 

> If I understand correctly when I use chmod g+s on the project directory 
> and I do this once the directory is created every addition and 
> modification of whatever user will make sure that the file is in the 
> right group 

Yes. This  includes newly created directories (which also will get their SGID
bit set if all's well).

> and the file belongs to the creator (in the case of adding a 
> new file) and preserves the ownership when committing a change.

no: it's about gid, not uid. So 

>> What is the underlying problem you are trying to fix?

> See above, that is the basic idea. New files are owned by their creator 
> and stay that way (this happens by default right?)

No. There can be several checked-out copies of files, which will each have
the ownership and default permisssions of the person that checked them out. 

If you talk about 'the' ownership of a file, I can only assume that you mean
the repository file ($CVSROOT/foo/bar,v). This will be owned by the latest
commiter. But this is pretty much irrelevant with group-write access (which
is the common mode of operation). 

>  others in the group 
> have write rights on the file (in normal shell environment)

Which file ? checked-out copies: full rights. Repository files: everything
read-only for everyone. This is because CVS used to use RCS, which relies on
access permissions to know what it's doing. 

>  and if 
> applicable commit rights on it. Others not in the group have no rights.

I can't seem to find you original post, so I guess you want to use access
control lists; this is not very common nor considered useful with CVS.

> This is the first of a series of activities to come to a repository 
> which can hold secure files (customer owned) and free sources mixed into 
> one repository. We used to have different repositories for it, but I 
> have decided to plunge in and try to have them in one repository without 
>   daily manual maintenance to get guarantees that information is secure.

Don't use different repositories for this; use the same repository with
different modules. Check customer-owned files/trees into their own vendor
branch, and lock it down. A quick search on gave this:


The mail transport agent is not liable for any coffee stains in this message
Philip Lijnzaad, address@hidden European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639                 Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           Cambridgeshire CB10 1SD,  GREAT BRITAIN

reply via email to

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