[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:
>> http://www.mail-archive.com/address@hidden/msg14117.html
> 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 groups.google.com gave this:
http://groups.google.com/groups?hl=en&threadm=H00009db0ada4da3.0991676620.kcopmp06%40MHS&rnum=3&prev=/groups%3Fq%3Dcvs%2Block%2Bbranch
Cheers,
Philip
--
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