Re: preliminary ACL support in cvs-nserver

[Greg A. Woods]

[ On Sunday, September 30, 2001 at 13:50:10 (+0400), Tobias Brox wrote: ]
> Subject: Re: preliminary ACL support in cvs-nserver
>
> 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.

This is all CVS-based internal ACLs can ever really be, at least without
a complete re-design and re-implementation of CVS from the ground up.

> 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.

Running CVS setgid or setuid is impossible to do safely -- you cannot
enforce accountability with CVS as it stands today.

Running CVS only as a server sufferes the same fallacy -- you cannot
enforce accountability with CVS as it stands today.

Setting up SSH so that cvs users can only run CVS is a different answer
to a different concern.  It certainly keeps accountability in the
picture but it doesn't make it possible to implement internal ACLs in
CVS -- indeed it makes it ever more obvious that ACLs must be enforced
by the filesystem if they are to be actually enforced (i.e. if they're
to be technical controls not just accident avoidance advice).

> 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! :-)

Not just a re-write, but a re-design.  Currently the *info hooks, for
example, provide far too much capability.

Of course anyone contemplating such a project should also try to study
the reasons for using version tracking tools and how they fit into a
larger SCM process.  ACLs on branches and files may just not make sense
(which is what I've been trying to hint all along!).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>