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

Collapse
4: Re: RFC: adding :ext: access option to OpenACS CVS (response to 3)
Posted by Jeff Davis on 02/05/04 09:56 AM
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.

Collapse
5: Re: RFC: adding :ext: access option to OpenACS CVS (response to 4)
Posted by Andrei Popov on 02/06/04 10:26 AM
Check savannah.gnu.org -- they have switched to *only* allow :ext: since the last year's break-in and compromise.  Look at this: http://savannah.gnu.org/forum/forum.php?forum_id=2752
Collapse
6: Re: RFC: adding :ext: access option to OpenACS CVS (response to 5)
Posted by Jeff Davis on 06/12/04 12:21 PM
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/cvs-chroot-proxy.pl" (based on bug reports I saw) which I can't find in a checkout of the savanah source.
Collapse
7: Re: RFC: adding :ext: access option to OpenACS CVS (response to 6)
Posted by Mark Aufflick on 06/20/04 10:01 AM
Hmm - if cvshome.org can be hacked via the pserver exploit (see https://www.cvshome.org/ & http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0396 )
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.