[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:
#!/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?