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

Re: AuthUserFile not specified in the configuration

From: Justin Mrkva <mail_at_justinmrkva.com>
Date: Fri, 4 Apr 2014 06:54:39 -0400

Yes, it is readable. I also confirmed the command works.

In the meantime, I’ve tried a few additional things. I found a preinstalled (but unactivated) module called mod_auth_digest_apple, so I deactivated mod_auth_digest in favor of the Apple-specific one. There’s one important difference: the Apple version does _not_ need the AuthUserFile. Instead, it uses the OS X user database. Oddly, Apache still complains about AuthUserFile, but it succeeds. I expect it masquerades as mod_auth_digest for compatibility, so Apache still expects the file to be specified even though it’s not needed.

Before, authentication succeeded in the browser but gave the error and returned 500 for the client. Now, authentication seems to succeed on _both_ the browser and the client, which is a step in the right direction I guess.

However, there’s a new error on the client instead of a 500:

    svn: E175013: Access to 'https://server.example.com/svn/repo' forbidden

This error again only occurs for the client, the browser is still able to browse repos with no trouble. I confirmed again that all files (such as /Library/Subversion/svnaccess) are properly readable. Additionally I modified svnaccess to remove rw permissions, refreshed the browser, and the repos disappeared from the listing. Reenabling rw for my user or for all users caused it to appear again, so it is definitely obeying the svnaccess file.

As for the OPTIONS request being treated differently somehow, that is… actually very possible. I set LogLevel in httpd.conf to debug and watched the error messages, but I never saw anything that looked suspicious. I’ve pasted the httpd.conf file at https://gist.github.com/anonymous/d84e4e9721a49789f846 if someone wants to take a look.

I did try using curl to send GET and OPTIONS requests to the /svn/ path of the server. GET responded with 200, OPTIONS responded with a 403. So that looks like the problem. I have no idea how to fix it, though.

A small excerpt of just the SVN relevant sections of httpd.conf:

    LoadModule auth_digest_apple_module ${SERVER_INSTALL_PATH_PREFIX}/usr/libexec/apache2/mod_auth_digest_apple.so
    LoadModule dav_svn_module /usr/local/libexec/mod_dav_svn.so
    LoadModule authz_svn_module /usr/local/libexec/mod_authz_svn.so
    Location /svn/>
        DAV svn
        SVNParentPath /Library/Subversion/Repositories
        SVNListParentPath on
        
        AuthName "UserWebDAV Gateway"
        AuthType Digest
        AuthzSVNAccessFile /Library/Subversion/svnaccess
        Require valid-user
        
        Order allow,deny
        Allow from all
    </Location>

On Apr 4, 2014, at 6:06 AM, Ryan Schmidt <subversion-2014_at_ryandesign.com> wrote:

>
> On Apr 4, 2014, at 04:24, Daniel Shahaf wrote:
>
>> Does 'sudo -u _www wc -l -- /private/etc/svnauth.htdigest' work?
>>
>> (I'm suspecting /private might be unreadable by _www.)
>
> On a normal OS X system, /private and /private/etc have rwxr-xr-x permissions.
>
Received on 2014-04-04 12:55:18 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.