[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] A new (simple) authentication mechanism for svnserve

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-07-29 07:25:44 CEST

On Thu, 2005-07-28 at 07:22 -0400, chrislott@spamcop.net wrote:
> Https access works, but requires an admin to get involved every time a user
> creates a new repository or wants to change the list of authorized users for a
> repository.

I'd be a little surprised if you can't get this down to "every time a
user creates a new repository," by convincing httpd to authenticate
against a password file owned by the user. But I'm no httpd expert.

> The downside is that the svnserve password file in every repository's "conf"
> folder must be readable by the svnserve process. It could be owned by the svn
> user id and mode 444, but that would prevent users from changing things.
> Because all of our unix users work in a big, shared-via-NFS world, the net
> result is that every respository owner can read any other shared repository.
> (Yes, we use FSFS as the repository format.) This is not currently a fatal
> problem but it sure isn't nirvana.

You might look into making a setgid script which can chgrp -R a
directory to group svn and chmod g+s it. Then repository owners
wouldn't have to be in the svn group. The script would only need to be
run when a new repository is created; the g+s bit will keep new files
and subdirectories of that directory owned by the svn group.

If your NFS environment doesn't recognize the concept of setgid, then
you might need something automated or semi-automated which runs on the
NFS server. Properly authenticating users to this service could be an
issue... but if you're using NFS, you probably don't have very good
authentication anyway.

Another option is to use file:// access to the repositories instead of
svnserve, and a group management system which allows users to create and
manipulate groups. (At MIT, we use AFS instead of NFS and have a
homegrown system called Moira which provides group management, but
that's a lot of infrastructure.)

> I'm sure not an authentication or encryption expert, but I can try to work on
> this problem if someone can get me started. (No, I'm not a student, this is
> not a summer of code for me. :-/)

What Dave proposed wouldn't solve your problem. The hashed password
stored in the password file could, under his system, be used to
authenticate to the Subversion repository (using a modified client) just
as well as the cleartext password can in the current state of affairs.
CRAM-MD5 operates on a shared secret; the server has to know the same
thing the client does.

More traditional password authentication has the server knowing a
one-way hash of the secret known by the client. The client tells the
server the secret, and the server hashes it and matches the result
against the stored hash. But that wouldn't be a very good solution to
your problem either, because:

  * Dictionary attacks are pretty trivial these days. Since, in your
environment, any repository owner would have access to the one-way
hashes of the passwords, said owner could run an offline
password-cracker against those hashes and probably recover at least 50%
of the passwords.

  * In CRAM-MD5, the client does not transmit the secret to the server,
but uses the secret to answer a challenge given by the server. In more
traditional password authentication, the client does have to transmit
the secret to the server, raising the possibility that someone might
sniff it across the wire. SSL can help, but it's (a) a little
complicated to administer, and (b) usually not terribly secure, since
most environments cop out and do not securely transmit the server's
public key to the client.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 29 07:26:47 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.