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

Re: Possible auth bug in SVN?

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Wed, 20 Aug 2008 14:40:54 -0500

On Aug 20, 2008, at 07:52, Davyd McColl wrote:

> I have Subversion version on a windows XP host (server
> and client tools). I'm building a system which will use the
> niftiness of Subversion hooks to do some of the work for us
> (currently working on a post-commit.exe). In the course of testing,
> I've created and destroyed repositories, removed cached auth
> information from my profile, and so forth. The following oddity
> appeared today, which I would like to bring to the developers'
> attention, *in case* it's a problem (perhaps there is some
> perfectly rational explanation for this, I don't know?)
> Anyway, the scenario was as follows:
> I have a repo called "helloworld", which I can get to via svn://
> myhostname/helloworld. Some time in the not too distant past (last
> week-ish, iirc), I cleared out my cached auth informaction under %
> PROFILE%/Application Data/Subversion, which should have effectively
> meant that I would have to log in to the server at the next SVN
> server-side "transaction" (for lack of a better word) -- ie the
> next "svn up" or "svn commit". Now, I managed to do the following,
> *without* logging in, in the base of a checked out version of this
> project:
> svn mkdir newdir
> echo "rubbish" > newdir\newfile
> echo "more rubbish" > newdir\newfile2
> svn add newdir\newfile newdir\newfile2
> svn commit
> <at this point, the svn client spawns gvim, i put in a message, and
> the svn client transmits the change to the repository WITHOUT ERROR>
> Then, I did:
> svn del newdir
> svn commit
> <enter comments, save comments, svn commit goes through just fine>
> A few minutes later, however, just for chuckles, I issued "svn up"
> in the same dir, and was presented with a request for a password
> for my username, which I duly entered, and I was authorised. The
> update went through after that with no hassle.
> So now, since I hadn't inspected my auth cache before all of this,
> I'm left with one of two scenarios:
> 1) I had authorised some prior time, and that's why my svn adds and
> svn dels could commit; however, if this is the case, how come I'm
> presented with an auth request again?
> 2) I was allowed to commit changes to an SVN repository *without
> authorisation*.
> (1) presents a minor glitch which just confuses the user; (2)
> should be of much greater interest to SVN devs. So far, I've been
> unable to replicate the problem. I know this doesn't really help
> all that much (sorry!), but I have tried simple stuff like deleting
> my auth and trying again (requires auth before any of the commits
> outlined above). I also don't really expect anyone to get all
> excited and do something about this -- it's just a report in the
> hope that perhaps someone with more knowledge of the internals of
> SVN might be able to think of how I triggered this behaviour, and
> perhaps fix it (: On the other hand, is there any way that my post-
> commit hook could have caused this? At present, it doesn't do much,
> simply writing out the arguments that it received to a file...

It is possible and valid (though not recommended) to configure a
Subversion repository to allow read and write access without

You could look at the log for the revision that you were able to
commit without needing to authenticate. Does it show your username as
the author of that revision? If so, then your auth credentials were
cached and Subversion used them. But if the author field is blank,
then the repository is configured to not require authentication. See
your svnserve.conf.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-20 21:41:19 CEST

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.