Is there some reason I shouldn't view this as a security hole? Without debating
the lack of real security in pserver mode already, an open source client such as
CVS's is so easily hackable that a sensitive system becomes even more insecure.
User X can easily log in and make changes which will be logged as having been made
by user Y.
I can see using a trusted authentication system to set the variable, but use the
CVS client???
I think even hacking SSH to do this is fairly insecure, as there is no way that
I know of to verify that the SSH client is "pure" and it can only authenticate that
key and user are valid on a server machine. Therefore, if an SSH client
authenticates on the server as the generic user and sends a simple "my name is X"
from a particular machine, there is no way to know that the user is really X on
that machine. And that doesn't even take into consideration the nightmare of a
user setting up a clean machine and adding any user ids to it that they'd care to
and connecting from there. I imagine that if SSH servers could authenticate
against each other and verify their and their users identities something might be
riggable. Is that possible as things stand?
Derek
--
Derek Price CVS Solutions Architect
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan".
The Pledge of Allegiance does not end with "Hail Satan"...
- Bart Simpson on chalkboard, _The Simpsons_
Noel L Yap wrote:
> Yes, exactly. This is what happens now with pserver. Ideally, CVS should use
> an environment variable REMOTE_USER that's set by authentication software (eg
> SSH). But since I don't want to risk breaking SSH, I don't want to make the
> change in it.
>
> Noel
>
> [EMAIL PROTECTED] on 2000.06.21 11:43:01
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Proposal: have client CVS send remote username to server CVS
>
> So, if I understand you correctly, you're proposing to map a single user on the
> server (connecting via SSH, RSH, or whatever) to many names within CVS, based on
> the username seen by the client?
>
> Derek
>
> --
> Derek Price CVS Solutions Architect
> mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
> --
> Once at a social gathering, Gladstone said to Disraeli, "I predict,
> Sir, that you will die either by hanging or of some vile disease".
> Disraeli replied, "That all depends, sir, upon whether I embrace your
> principles or your mistress."
>
> Noel L Yap wrote:
>
> > I was able to find the spot after all. To summarize, the patch will have the
> > CVS server record the client username rather than the server username within
> the
> > CVS logs. I have not added a new CVSROOT/config option. When using pserver,
> > there'll probably be just a little bit of extra processing, but there should
> be
> > no noticable difference (including in behaviour).
> >
> > I'll (try to) post a bunch of patches to SourceForge RCVS next week (yeah,
> yeah,
> > I know I've been saying this for the last couple of weeks; but /this/ time I'm
> > /really/ gonna do it ;-)
> >
> > Noel
> >
> > [EMAIL PROTECTED] on 06/16/2000 03:31:07 PM
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Re: Proposal: have client CVS send remote username to server CVS
> >
> > OK, I've decided to make such a patch. I'm not sure how to go about doing it,
> > though. I can't find where in the code the client can send initial
> information
> > (ie remote username) over to the server. Can anyone give me a pointer?
> >
> > Thanks,
> > Noel
> >
> > [EMAIL PROTECTED] on 06/11/2000 09:55:55 AM
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED] (bcc: Noel L Yap)
> > Subject: Re: Proposal: have client CVS send remote username to server CVS
> >
> > [EMAIL PROTECTED] on 2000.06.10 19:23:23
> > >Pserver authentication is completely adequate :) It just runs over the
> > >insecure channel and has unclean mixage of various subsystems in its
> > >current, non-nserver form.
> >
> > No, it's not, it's extremely prone to replay attacks and stolen .cvspass
> files.
> > Furthermore, the encryption of the .cvspass file is reversible, meaning that,
> > given a .cvspass file, /anyone/ can figure out the plaintext password.
> >
> > More than that, any code dealing with security _must_ be audited to ensure
> that
> > it is secure. I don't think that's been done to any of the CVS code; I don't
> > think it should be necessary.
> >
> > Besides, nserver doesn't address the concerns of those who want to use
> > CVS_RSH=ssh.
> >
> > Noel
> >
> > This communication is for informational purposes only. It is not intended as
> > an offer or solicitation for the purchase or sale of any financial instrument
> > or as an official confirmation of any transaction. All market prices, data
> > and other information are not warranted as to completeness or accuracy and
> > are subject to change without notice. Any comments or statements made herein
> > do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
> > subsidiaries and affiliates.
> >
> > This communication is for informational purposes only. It is not intended as
> > an offer or solicitation for the purchase or sale of any financial instrument
> > or as an official confirmation of any transaction. All market prices, data
> > and other information are not warranted as to completeness or accuracy and
> > are subject to change without notice. Any comments or statements made herein
> > do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
> > subsidiaries and affiliates.
> >
> > This communication is for informational purposes only. It is not intended as
> > an offer or solicitation for the purchase or sale of any financial instrument
> > or as an official confirmation of any transaction. All market prices, data
> > and other information are not warranted as to completeness or accuracy and
> > are subject to change without notice. Any comments or statements made herein
> > do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
> > subsidiaries and affiliates.
>
> This communication is for informational purposes only. It is not intended as
> an offer or solicitation for the purchase or sale of any financial instrument
> or as an official confirmation of any transaction. All market prices, data
> and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements made herein
> do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
> subsidiaries and affiliates.
