Re: preliminary ACL support in cvs-nserver

[Tobias Brox]

[Alexey Mahotkin - Sun at 04:28:16AM +0400]
>   Rationale: a very common task is "let support engineers commit
>   patches to the stable branch, and not to the trunk, which is for
>   main developers only";

*nod*.  Or the opposite, untrusted developers might commit to an
experimental branch, while the main developers decides what should be
allowed to go into the official version - or what is to be regarded as
"clean bugfixes" and go into the stable branch.

I hope you've read through the ACL discussions that have been the
last days.  From my point of view, ACLs in CVS could be useful, though not
so important that I would try to deal with it myself, at least.

>       - tag (non-branch) revisions (this includes moving and
>         deleting tags);

I'd favor a distinction between deleting (thus moving) and creating
(non-branching) tags.

Rationale: 
Maybe an individual developer can want to set a tag, to be able
to go back to this exact version of the source.  It's a trivial thing to do,
it wouldn't harm anyone, and I'd say that's one of the things tags are to be
used for.  Then again, it would be very annoying if some other causual
developer removed or deleted this or other tags on his own liking.

I can also see situations where it might be a good idea that somebody only
are allowed to tag the files they have write permission on. 

Rationale:
Tags can be used to mark certain milestones.  There might be an agreement
about using the tag "m-4" for "milestone 4" which is properly defined in
some design document.  One developer might, on a casual thursday, find that
his part of the project seems to work, and accomplies with all the targets
defined for "milestone 4" in the design documents.  He should then be
allowed to tag _his_ files with "m-4" before continuing with the targets for
milestone 5 - without worrying whether the other developers have reached
milestone 4 yet or not.

I wouldn't say it's important ... but then again, if ACLs are to be
implemented in CVS, it should be done Properly, to cover any need that might
arise.

> Quality Assurance
> ==================
> 
> All of the ACL-related functionality is fully unit-tested and
> (hopefully) feature-tested.

I hope you've read through the discussions that have been here.

ACL is a security thing, and security things can never be covered only by
testing.  At least, the sources should be carefully investigated by several
parties.

If the purpose of ACL merely is to avoid that somebody by accident steps on
somebody elses toes, it might not be that important - but at least it has to
be docmented very clearly.

Of course, if ACLs are to be secure, people cannot be allowed access to the
repository - all operations has to go through CVS.  So, either CVS needs to
be setgid or setuid, or it needs to run strictly as a server.  Setting up
SSH so that the cvs users can authenticate and start CVS, but nothing else,
is probably the best solution.

Then it's important to safeguard that there are no possibilities to
shortcircuit CVS.  There are talkings that CVS would need almost a ground-up
rewrite to be secure, and the info pages also states that once cvs has write
persmissions to repository it is possible to execute other commands through
CVS.  It has to be dealt with if ACLs are to make sense.  Good luck! :-)

PS: msk.ru, that's in SPb, isn't it?  Could be nice to meet over a beer or
something - I'll be in SPb until the end of the week.

-- 
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/