On 12/01/2013 11:14 PM, Ben Reser wrote:
[...]
Is there a way to prevent the casual browsing while avoiding the
E220000 error?
The reason you're getting the error is because internally
mod_dav_svn is running a GET sub-request to see if you have the
permissions required to read the root of the REPORT request that
you're making to do the checkout.
Apparently so; and this appears to be new (recent) behaviour. Quite why
svn believes it needs to check the permissions one level above where it
was told to go is unclear to me, but I'm sure wiser heads have thought
this one through.
The GET request fails because your LimitExcept block is requiring an
authenticated user in order to execute a GET request. However, since
authentication has not been required for the REPORT request the
client never received the 401 to prompt it to start providing
authentication details.
OT but I can't see why the REPORT request didn't need authentication;
but it's moot anyway.
The GET subrequest can be avoided by setting "SVNPathAuthz
short_circuit" (which you probably want to set anyway). However,
this still doesn't solve your problem because then your authz file
will be consulted and you don't allow anonymous users read access.
At that point it would seem that it ought ask my client to authenticate,
and it would prompt me for the credentials.
The interaction with the client hasn't changed the behavior even
with this setting so the user making the REPORT request is still
anonymous.
OK.
The next possible setup is to set "SVNPathAuthz off". This disables
this check entirely and if the actual request the client made is
allowed then it assumes the secondary paths the request makes are
allowed as well. I.E. you're not using path based authorization and
the client has the same level of access across the entire repo. If
you used a separate Location for each repo rather than SVNParentPath
and set the access restrictions directly in httpd.conf for different
users this would be true. However, it still would have a hole.
I haven't yet figured out how to phrase the conf to do path-based. But
it's not urgent.
With "SVNPathAuthz off" your configuration would have been allowing
anonymous users to receive file content by doing checkouts with a
client set to do bulk updates (including the file content in the
REPORT request as opposed to producing a skeleton REPORT response
that contains URLs that the client does GET requests on to retrieve
the file content). Which would have ultimately made your security
come down to obscurity of your URLs.
Which is what it was on the previous server. Only one URL was in use by
people other than me, and I know and trust them all.
Just not a good way to go as a matter of principle.
You can see this with this configuration by passing '--config-option
servers:global:http-bulk-update=yes' and noticing that the client
would never ask your authentication details and would still retrieve
the full checkout (assuming the credentials aren't cached, if they
are remove the cached credentials or just note that none of the
requests have a user attached in the access log).
I believe the commandline svn client under Ubuntu *does* cache the
credentials, as it has only ever asked me for them once per URL since I
moved to the new server.
The correction configuration here is to remove the LimitExcept block entirely
(though leaving the contents inside it). E.G.:
<Location /svn>
DAV svn
SVNParentPath /var/lib/submin/svn
AuthzSVNAccessFile /etc/svn.authz
SVNPathAuthz short_circuit
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/svn.auth
Require valid-user
</Location>
I am unclear on the distinction between /etc/svn.authz and /etc/svn.auth
here. The filename I am using for AuthUserFile is /etc/svn-auth-file; I
don't have any other svn file in /etc.
However, this may not be needed...
The purpose of such a LimitExcept block is to allow anonymous read
access while requiring an authenticated user for write access.
However, what you're wanting is to only allow authenticated access.
Correct.
Technically you don't need the AuthzSVNAccessFile either,
In fact it doesn't work with it at all; I get
$ svn up
Updating '.':
svn: E175013: Unable to connect to a repository at URL
'http://xxx.xxx.xx/svn/yyyyy'
svn: E175013: Access to 'http://xxx.xxx.xx/svn/yyyyy' forbidden
If I comment out AuthzSVNAccessFile, I still get
$ svn up
Updating '.':
svn: E220000: Not authorized to open root of edit operation
However, if I also comment out the SVNPathAuthz short_circuit line, it
all works correctly.
however if you wanted to require different authenticated users for
different repos as you've explained then you'd need to use SVNPath
and have a separate Location block for each repo.
I will work on this one.
If you only ever intend to have a small number of repos and not using
path based access control (separate permissions for different paths
inside the repo) then I'd probably go that route since using
mod_authz_svn has a somewhat high performance cost. You're really not
using path based authentication and are just using the authz config
to require different users for different repos.
If I can master this, then there will be a moderate (<50) number of
repos for various projects for other people. I then need to decide if I
want to use path-based access or not.
If you want to stay with using authz (for the reasons given above)
then I would recommend including "SVNPathAuthz short_circuit" because
the only way your authorization would change per path would be based
on the results of the svn authz file, so you can get much better
performance by avoiding the need to execute sub-requests and instead
just ask mod_authz_svn directly about secondary paths.
Unfortunately, enabling SVNPathAuthz short_circuit causes the E220000 error.
I'd strongly urge a careful reading of:
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz
There goes my bedtime reading...
I'd also urge you not to stray too far from the examples provided
there on the httpd configuration side. The httpd authorization and
authentication systems are really complicated and twisty and things
do not always work the way you might expect due to some odd
iteractions between the pieces.
Thank you very much indeed for the comprehensive explanation and a
working solution.
///Peter
