>> A good description from the list archive: >> http://www.mail-archive.com/[email protected]/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, [EMAIL PROTECTED] 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
