On Mon, 2015-09-07 at 10:20 +0200, Branko Čibej wrote: > [Please keep the conversation on-list, others are interested in it, too. > I'm replying privately, since I can't just make your private message > public without your consent; but please follow up on the list, if you > don't mind.] > > On 07.09.2015 10:07, Tony Butt wrote: > > On Mon, 2015-09-07 at 09:59 +0200, Branko Čibej wrote: > >> On 07.09.2015 02:16, Tony Butt wrote: > >> > >>> On 07/09/15 10:10, Tony Butt wrote: > >>> > >>>>> # Compression options > >>>>> AddOutputFilterByType DEFLATE text/html text/plain text/xml > >>>>> SetInputFilter DEFLATE > >>>>> > >>>>> # Krb Authentication > >>>>> Include /etc/apache2/krb.conf > >>>>> > >>>>> AuthDBMType default > >>>>> AuthDBMGroupFile /srv/www/groupsdb > >>>>> <RequireAll> > >>>>> Require group software hardware > >>>>> Require valid-user > >>>>> </RequireAll> > >>>>> > >>>>> AuthZSVNAccessFile /srv/svn/access > >>>>> > >>>>> > >>>>> </Location> > >>>>> > >>>>> > >>>>> I installed the subversion 1.9.0 RC a little while back on this > >>>> machine, > >>>>> all OK. > >>>>> Installed subversion 1.9.0 release Monday, had to set > >>>>> --enable-broken-httpd-auth > >>>>> to build successfully. Went to the apache config and ensured > >>>> that nobr...@wandisco.com > >>>>> unauthenticated access was possible to the document root. All > >>>> OK. > >>>>> I installed subversion 1.9.1 yesterday, built and installed OK. > >>>>> On testing repos access, I can browse to > >>>> http://hostname/repos/ , > >>>>> but any attempt to access http://hostname/repos/name1 > >>>>> fails, with this message at the browser. > >>>>> cea_sw_dev/ > >>>>> "Unauthorized This server could not verify that you are > >>>> authorized to > >>>>> access the document requested. Either you supplied the wrong > >>>> credentials > >>>>> (e.g., bad password), or your browser doesn't understand how to > >>>> supply > >>>>> the credentials required." > >>>>> > >>>>> Reverting to Subversion 1.8.13, or 1.9.0 resolves this. > >>>>> Changing the configuration to not use SVNParentPath, by > >>>> specifying > >>>>> individual repositories with SVNPath resolves this too. > >>>>> Some interaction between the svnauthz changes and SVNParentPath > >>>> seems to > >>>>> be broken > >>>> When you upgraded Subversion, did you also restart httpd? (Using > >>>> 'apachectl graceful' or 'apachectl restart' or reasonable > >>>> equivalent.) > >>>> br...@wandisco.com > >>>> -- Brane > >>>> > >>> cea_sw_dev/ > >>> Sorry for the delayed reply, I have been off work sick for a while, > >>> and am only just subscribing to the list. > >>> Sorry also for the somewhat dodgy reply format too, working around > >>> the non-subscription. > >>> > >>> Yes, I did restart httpd - I went through the sequence of changing > >>> installed versions at least twice as well, restarting each time. > >>> > >>> I looked at the changelog for 1.9.1, and didn't see anything > >>> obvious, but... > >>> > >>> I can easily test against our config if there is a change you want > >>> tested - OTOH, it might be configuration or user error (unlikely, > >>> but possible). I'm not new to subversion though, so I hope I covered > >>> the obvious stuff... > >> > >> At the moment, considering another report, it seems that the problem > >> stems from an interaction between Kerberos authentication and one of > >> the recent security fixes in either httpd or Subversion (CVE-2015-3185 > >> or -3184). If that's the case, then it's probably not specific to > >> 1.9.1 but exists in 1.9.0, 1.8.14 and 1.7.22 as well, always in > >> combination with httpd-2.4.16. > >> > >> I'm trying to track this down but haven't had much success yet. > >> > >> -- Brane > > I was able to test this on the same system, with Subversion 1.9.0, > > Are you sure you were using 1.9.0, not one of the release candidates?
I'm fairly sure, but will double check shortly > > > and > > 1.8.13 as well, and did not see the same problem. > > 1.8.13 does not have the CVE-2015-3184 security fix. > > > I don't have 1.8.14, but can build and test it if you like. > > Please do! I'll do that soon too > > > I can probably also test against mod_auth_sasl, if that would help - we > > run that on an older machine, and I should be able to copy the config. > > It would be good to compare SASL and KRB, yes. That will take a little more work, I'll reply when I have it done. > > -- Brane -- Tony Butt <tony.b...@cea.com.au> CEA Technologies
signature.asc
Description: This is a digitally signed message part
