Re: "cvs server" accepts but ignored --allow-root

[Derek Robert Price]

Derek Robert Price wrote:

> Tim Riker wrote:
>
> > Not sure how to do a test for this. src/sanity.sh does one rsh test, 
> > but I don't think you can alter the command it runs on the other end? 
> > I believe it does "cvs server" and I need it to do "cvs server 
> > --allow-root ${CVSROOT_DIRNAME}" which should work. Anything else 
> > like "cvs server --allow-root ${CVSROOT_DIRNAME}/foo" should get an 
> > error when the client tries to choose a different path.
> >
> > The current state is that "cvs server --allow-root 
> > ${CVSROOT_DIRNAME}/foo" _will_ allow setting the dirname to anything 
> > and will completely ignore the --allow-root without a warning or 
> > error message.
> >
> > CVS_SERVER cannot contain arguments, correct? I suppose you could 
> > create a script like:
> >
> > #!/bin/bash
> > exec cvs --allow-root /path/from/cvsroot_dirname $*
> >
> > and then put the scriptname in CVS_SERVER?
> >
> > Testing over rsh should work, but is kind of silly. I suppose an 
> > admin might provide a cvs wrapper as above and hide the real cvs 
> > binary. This really  is used with ssh authorized_keys as explained in 
> > the original message.
>
>
>
> Testing over RSH should be fine - CVS_SERVER can be set on the client 
> end and CVS will use the same code whether executed by SSH or RSH.  No 
> security restrictions are necessary in the tests scripts - you know 
> what you told it to run - the test isn't like a user who might try and 
> change it.
>
> You might also try running something akin to the pserver, server, and 
> server2 tests - those exec `cvs --allow-root=X pserver' and `cvs 
> server' on the command line then feed fake protocol data in on stdin 
> and read stdout to see if they are working properly.  You could 
> probably cut and paste a few of those tests even, as long as you added 
> one that got the failure message.  I think you need to test three 
> cases - a working checkout without --allow-root specified, a working 
> checkout with --allow-root specified, and a forbidden checkout with 
> --allow-root specified.
>
> Derek


Incidentally, on my machine, your patch doesn't pass `make check' as it 
stands.  This probably means you did something incorrectly.  It is 
preferred that the code be changed to match the tests rather than 
visa-versa unless it can be proven the new failure is only the result of 
a former bug encoded in the test suite.  

> ** expected:
> .* LOVE YOU
> E Protocol error: Root says "/tmp/cvs-sanity/1" but pserver says 
> "/tmp/cvs-sanity/cvsroot"
> error
> ** got:
> I LOVE YOU
> E Bad root /tmp/cvs-sanity/1
> error
> FAIL: pserver-5


In this case, it might only be that your new error message doesn't match 
the old, and that the old test really should fail at the new location, 
but that needs to be verified.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
OK, who stopped payment on my reality check?