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

RE: user authentication

From: Ray Johnson <Rayj_at_ingenio.com>
Date: 2004-11-15 17:43:31 CET

 

Sure - I'd be happy to explain in more detail. We are currently using the NTAuth stuff in Apache so that users can use the same authentication they use to log into their computer. We have the following issues with the current implementation:

1) Since SVN 1.1.1 - the "svn log" command has become completely unusable for us. This is due to the "security fix" where each path in the history of a file is checked for security. Since we did a massive import of our repository it means the command apparently has to check the security for several thousand paths. This causes "svn log" to take longer than 5 minutes for a file of minimal history. As I understand it this is more related to path authz - but is related to the whole Apache security package. (Not sure how much of the cost is authentication on all those paths or just the cost of looking at so many paths.)

2) The NT Auth stuff requires a user name of "domain\username". Ideally, we would prefer folks to just put in "username" as the domain is the same for everyone. Aside from the "ease of use" issue, it is also a problem for us because it makes "svn ls --verbose" useless to us. One would use "svn ls --verbose" to see who modified a file in a directory - but svn will truncate the username to 8 characters - all we ever see is the domain name. If we could do our own auth and use username only we could work around "svn ls --verbose"'s design flaws.

2a) If I was implementing my own authentication I would also make the username case insensitive. It is very common for me to have to explain to new Subversion users that while everywhere else their username is case insensitive - in Subversion it is not.

3a) The "domain\username" scheme is also a pain with the svn client. When the svn client needs to do auth (or re-auth because of a password change), it "guesses" your username as the username your logged into. However, it doesn't put the domain in - so it always guesses wrong. Getting rid of the domain would "fix" this issue. Alternatively, you could fix the client - but that somehow seems harder...

3) The Apache NT Auth stuff does not support NT Groups. While you can set up your own "groups" in Apache - we would much rather use the Active Directory groups we are already maintaining to use for path authorization. The entire point of using the NT Auth stuff is to reduce maintenance points and the current implementation doesn't quite go far enough.

A properly designed "hook" for authorization could allow us to fix these issues. It would also allow us to use our security model when using the "svn:" protocol - which would be nice.

Ray

P.S. - While on the topic of security - I'll also mention that caching the users password in clear text is a serious issue on a Windows machine. Windows security isn't that great to begin with but Subversion makes it much easier to get the users actual password. BTW, here is an exploit I've already seen: User asks "friend" for help with Subversion. Friend uses Subversion from users machine _without_ using "--no-auth-cache" on some command. Now user has access to friend's password. I kind of think --no-auth-cache should be default if your going to store password in clear text...

-----Original Message-----
Date: Sat, 13 Nov 2004 03:42:10 +0100
From: Branko Čibej <brane@xbc.nu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Subject: user authentication

Ray Johnson wrote:

> Does a request already exist to have an "authentication" hook in
> subversion? Something that could be used to tie into some custom
> system for authenticating users. We have been using the Apache stuff
> but it is less that satisfying.

I don't understand. Apache lets you create your own authentication
modules, and it already comes with a ton of them. How are the existing
tools in Apache unsatisfying, and how would you change them?

> (Particularly, with some of the security "improvements" made in 1.1.)

What "improvements" would those be? If you think we screwed up anyting
in 1.1 security-wise, plese explain what. We're always interested in
security issues.

> If such a request does exist (Which I'm guessing does but I'm not
> sure how best to find these issues...)

AFAIK it doesn't, at least not for DAV access.

> is it scheduled to actually happen anytime soon?

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 15 17:44:16 2004

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

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