[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Derek Robert Price
Subject: Re: "cvs server" accepts but ignored --allow-root
Date: Fri, 22 Nov 2002 08:24:55 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0

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:

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.


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:
E Protocol error: Root says "/tmp/cvs-sanity/1" but pserver says "/tmp/cvs-sanity/cvsroot"
** got:
E Bad root /tmp/cvs-sanity/1
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.



Email: address@hidden

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]