[ On Tuesday, October 29, 2002 at 09:10:44 (-0800), Shankar Unni wrote: ]
> Subject: RE: Per-modules readers/writers ?
>
> Well, is it the consensus of the maintainers that they will *never*
> accept any access control feature patches for CVS?
Nobody can arrive at any consensus on this kind of thing without first
seeing a complete design and functional specification for the proposed
features. You haven't proposed anything concrete enough yet to even
dream of whether it should be included in what we call CVS today.
> I.e. is the opposition to ACLs a matter of priorities, or philosophy?
> If it is philosophy, is it the position of the maintainers that ACLs are
> so evil that they will actively oppose any attempt by anyone to insert
> such a feature into CVS, in order to protect innocent users from this
> heresy?
You still don't seem to understand that it's a fundamental design issue
that hinges off the choice to use RCS for the underlying repository!!!!
You cannot securely implement access controls to internal structural
elements in CVS/RCS. It is simply not possible. There's no way to
expose those internal structures to the OS in such a way that it can
provide the necessary authorisation controls. If you're going to
implement security features then you'd damn well better make sure
they're for real because if you add some hack that gives a false sense
of security and then some other bumbling fool uses it without knowing
that it really doesn't provide any true security, then you would be
directly responsible (in the moral sense, and perhaps even in the legal
sense in some jurisdictions) for any damage done.
Philosophically I doubt anyone has any conflict with the _idea_ of
having finer-grained access controls for things like branches and tags
and commit logs and whatnot. However if you want to design and
implement something like that then you're going to have to toss out the
whole underlying RCS layer, and if you're going to do that then you may
as well just toss out the whole thing and start from scratch (well maybe
retain the command-line interface and perhaps the client/server protocol
for compatability's sake).
Even the suggestion of using a closed host system and perverting all the
security into the network server application isn't going to provide any
real security if it's based on anything even remotely related to the
current CVS code base. Even if you cleaned up the current code base so
that it could be better trusted as a security application; and
re-engineered some of the internal administrative control features (eg.
the way the *info files work) so that they could be trusted; you'd still
have to deal with network security issues because now you've made the
network and the workstations into the weakest links. That means forcing
use of something like SSH or TLS/SSL and providing for ways to manage
certificates so that they can be used for authentication. Once you do
that then you still have the workstations as the weakest link (which of
course they are even with the current use of SSH to access a CVS server).
Applications programmers really need to learn to leave security to the
OS and learn to deal with whatever limitations that might impose on how
they design their systems. As it turns out that's exactly the way CVS
was designed in the first place, and how it has been extended to be used
in a client/server configuration with RSH/SSH. If you want to use CVS
then you have to live with these design decisions. You can hack on some
false sense of security if you want but nobody who knows any better is
going to want to share that false security with you.
--
Greg A. Woods
+1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
