Re: Fw: need to force username of cvs 'action' when using shared SSH account

[Mark D. Baushke]

<#part sign=pgp address@hidden>
Keith Refson <address@hidden> writes:

>   "Tim Grotenhuis" <address@hidden> wrote:

> >  I just can't imagine that this hasn't been required before: a
> > single shell account with a used id of, for example, 'cvsuser'
> > requiring SSH, instead of pserver, authentication and access for
> > developers. The nature of CVS, that of tracking diffs and who did
> > what when, seems to be compromised in this situation. Thats all.
> 
> I have to agree with you here.  There seems to be an attitude of "CVS
> doesn't do this therefore I can't see why on earth you would want to" in
> all of the responses to your request.  The other posters seem blinkered
> by a last-generation "login" paradigm (despite the existence of
> pserver).  I suspect this attitude may be born of an ignorance of how
> SSH works and what it is capable of.

Hmmm... I am not sure I have seen that attitude myself, but I may be
biased.

The current sources have certain limitations and assumptions built into
them for normal configurations. However, they are sources and you can
modify them as needed for any purpose you desire.

> In fact what you want to do is just the recipie given in the O'Reilly
> book on CVS (usually a very reliable reference), and uses the SSH
> configfile to set the environment  variable LOGNAME.  The O'Reilly book
> says this works, but CVS currently ignores LOGNAME unless the uid is
> zero so I can only guess that the behaviour  was disabled at some
> previous release of CVS.

The getcaller() function in subr.c has always had to deal with intuiting
the real user who is doing the commit via LOGNAME or USER environment
variables only when "root" is doing the commit. It has been using
basically the smae logic since at least cvs version 1.3 when I started
using cvs.

> It's easy enough to patch the source to re-enable the previous behaviour
> -- it's a 2 liner.

I am not sure which patch you are talking about, there is no feature to
're-enable', but it is certainly possible to alter the behavior of cvs
given that you have the sources.

> I use a patched CVS to manage secure authentication for a
> restricted-access repository using exactly the scheme you propose. It
> works very successfully and has considerable advantages regarding
> login tracking and individual user authentication. Wen you need the
> ability to grant or deny access on an individual basis and track
> access it's a highly capable method.

And have you posted this set of patches for other folks to see and
possibly use? If not, why not do it now? If so, perhaps a pointer to
the previous posting with the diffs would be in order.

> No doubt there will be some ill-founded response to this worrying
> about security in some vague manner. But it's very easy to ensure that
> authorised users can do nothing outside CVS. I advise using the SSH
> config file to only allow execution of the "cvs" command, and for belt
> and braces run the account as a restricted shell (in case of any
> future security hole discovered in ssh or cvs).

I guess I don't understand why you feel the need to be so negative about
the folks on this list providing an 'ill-founded response' ...

The environment you are proposing is a highly specialized one as
compared with the general use of the cvs executable. I have no problems
with you (ab)using the cvs sources in any way that makes your life
better.

It is possible that a cvs server that is not operating in a restricted
environment may not enjoy the protections you are suggesting with regard
to using a restricted 'command="cvs server"' option via your SSH
configuration or the use of a restricted shell, so it is possible that
your particular patch may not be desirable for general acceptance in the
cvshome.org sources. This does not mean that they should not be made
available to others.

Of course, if you are using a patch that is not part of the standard
distribution, it may be that a future release of cvs will change in ways
that make applying your patches directly more difficult. So, part of
the cost of using an alternative version of cvs is maintaining it.

        Enjoy!
        -- Mark