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 nobrane_at_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.)
> >>>> brane_at_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.butt_at_cea.com.au>
CEA Technologies
Received on 2015-09-08 01:43:02 CEST