Forum OpenACS Q&A: RFC: adding :ext: access option to OpenACS CVS

Currently OpenACS CVS repository is provided via :pserver: option.  It is not very secure (in fact not secure at all), and also is not accessible, unless one has direct connection to the Net (unlike yours truly when in the office -- a firewall is between me and the rest & the best).

However, if :ext: option were enabled, one could:

export CVS_RSH="ssh"

cvs -z3 co -r openacs-5-0-0-final acs-core

even if one is behind a firewall, provided that he follows these simple instructions:

Therefore the question: can :ext: be enabled?

Posted by Jade Rubick on
Andrei, I believe it is. I use ext myself, except when doing anonymous checkouts.
Posted by Andrei Popov on
Hmm... I tried it some time ago and could not get it -- but you say 'except anonymous checkouts' -- this is the only co I can do, I am not a maintainer/commiter and don't have a login.

Let's just try it:

APopov@t1447 ~/projects/ncvs
$ export CVS_RSH="ssh"

APopov@t1447 ~/projects/ncvs
$ cvs -z3 co -r openacs-5-0-0-final acs-core's password:
Permission denied, please try again.

So, here's a problem (and I guess RFC should rather read 'adding anonymous user to :ext: option.'

Posted by Jeff Davis on
Are there any other projects you are aware of that do this? Sourceforge does not, as far as I can tell and I don't know of any other project that does. I would like to see an example of someone doing this...

Adding an anonymous user is more of a security risk than pserver (I have looked at restricted shells for cvs which would make it safer but to be honest I actually trust pserver more than doing that). The current anonymous user has /bin/false as it's shell and can't be used to log in.

Also, I did not really read all the way through the link you sent for the connect thing but it sounded like a port tunnel, and I don't see why you could not just use that to get through the firewall and still use pserver.

Posted by Andrei Popov on
Check -- they have switched to *only* allow :ext: since the last year's break-in and compromise.  Look at this:
Posted by Jeff Davis on
Andrei, can you get a tarball of a chroot tree for this or the source for the restricted shells they use? In particular, savanah uses "/usr/local/bin/" (based on bug reports I saw) which I can't find in a checkout of the savanah source.
Posted by Mark Aufflick on
Hmm - if can be hacked via the pserver exploit (see & )
then I guess we should be worried!

i really dislike having to enter passwords all the time and pserver is good for this.

Maybe the answer is one of the restricted cvs anon shells, and publish a private key for that user so that no logging in is required.

For commit enabled people (not me since the crash ... hint hint), I suggest that we design a two tier user system - give commit people a cvs login user with a restricted shell so they can only do cvs. That way they can store a key to avoid logging in with a password with less security implications.

Then a smaller set of those people who need ssh access to the box have a seperate user that gives them that access for which they are prevented from using a key to login with.

I can't imagine that a high percentage of committers really need ssh access to the box.

We really shouldn't ignore this.

Or we could switch to subversion, but i'm not really a fan of doing this as documented elsewhere.