Re: CVS woes: .cvspass

[Robin Rosenberg <robin.rosenberg.lists () dewire com>]

On Wednesday 04 August 2004 22.35, Greg A. Woods wrote:
> [ On Thursday, July 29, 2004 at 16:30:07 (+0300), Delian Krustev wrote: ]
>
> > Subject: Re: CVS woes: .cvspass
> >
> > On Tuesday 27 July 2004 23:20, Greg A. Woods wrote:
> > > Anyone using the CVS pserver mechanism for anything other than totally
> > > anonymous access gets only what they deserve.
> >
> > brr, do not forget that the security might be guaranteed on different
> > layers. E.g. ipsec secures the insecure protocols(the ones that transfer
> > data in plain text or with weak encryption), such as telnet or cvs
> > with pserver.
>
> Nope, sorry, but that's just not possible, at least not with CVS pserver.
>
> The unix security model, within which CVS is designed and implemented to
> work, _requires_ unique user-IDs for each and every unique human user.
>
> This is in fact a basic, fundamental, requirement of all systems of this
> type.
>
> CVS is not, and cannot be, a security tool so running it as root and
> pretending to have it do all your authentication and authorisation flies
> directly in the face of the underlying system security model and leaves
> you with no real and verifiable accountability whatsoever, and it also
> leaves you open to the possibility of yet another vulnerability vector
> in the form of the unaudited CVS code base.  Remember that the vast
> majority of all security incidents originate internally to the
> organisations they affect.

With 1.12 CVS can (and that seems to be the default) use system
authentication methods like PAM and does setuid etc before doing any cvs 
operations, which takes places as the respective user. It won't even let
me add users in CVSROOT/passwd. It does allow me to set a different password
for CVS acess though.

But also 1.11 did setuid etc before doing CVS operations. 

-- robin