On Sun, Aug 06, 2000 at 07:11:07PM -0400, Greg A. Woods wrote:
> No, the flaw in cvspserver is that it effectively merges the identities
> of all unique users into one system level identity.
Uhh.. no. Read up on pserver. It performs a setuid/setgid to the user id
of the user logging in to it.
This is yet another advantage my chroot patch provides to pserver: you
get to put a separate password file in the chroot area and have user ids
that exist only for CVS, further isolating it from the rest of the system.
And before you say it: remember the patch checks that you are non-root
before proceeding, so you can't authenticate yourself as root somehow.
> Unfortunately since
> CVS relies by design on system level identities for accountability
> purposes, as well as for finer grained ACLs, these features are all lost
> with cvspserver.
Uhh.. no. Read up on pserver. It performs a setuid/setgid so you can
go right ahead and use unix groups and user identities to control access.
> The CVS client/server protocol was actually designed to assume that the
> connection it was using had already been properly authenticated and
> authorised, and not un-coincidentally that's exactly what RSH or SSH or
> something similar provide.
It's also not coincidental that pserver performs the authentication
separately and then hands control down to the lower level just as ssh
would have done.
No, pserver isn't sensibly implemented like ssh is. But it does the
same thing. You don't do yourself any service by pretending that pserver
has a different design flaw than the one it really does have.
> The only "fix" for cvs-nserver is to completely remove the ability to
> support a non-system user. In essence this basically does away with the
> need for cvs-nserver in the first place so far as I can see (because it
> means all you're really doing is re-inventing SSH or SSL or SRP, etc.).
I thought nserver was implemented on top of SSL. But what do I know,
maybe it isn't.
Justin
