On 12/1/13 6:39 AM, Peter Flynn wrote:
> I have a number of svn repositories running under Apache+subversion on
> CentOS6/64, with Submin to provide a web GUI to manage them:
>
> server.name/svn/foo
> server.name/svn/bar
> server.name/svn/blort
> etc
>
> All of them are private; all but one of them are single-user (me) so
> that I can carry on working from any of my machines in multiple
> locations. One of them is shared with colleagues on a project: they all
> have read/write privs on that repo.
>
> The URIs are not published or linked, and my colleagues are all well
> aware of the need to keep their shared URI private. But the requirement
> is that none of them must be open to casual read access via a web
> browser, in case someone happen to stumble upon or guess the URI.
>
> I am having problems getting the access privs right, as they keep
> causing "svn: E220000: Not authorized to open root of edit operation"
> during an svn up. However, in a long exchange with the very helpful
> submin support
> (https://ssl.supermind.nl/collab/projects/submin/ticket/336) we have
> failed to identify settings that work.
>
> Currently the svn/conf/authz file says
>
>> [groups]
>> dev = a,b,c,d,e,me
>>
>> [foo:/]
>> @dev = rw
>>
>> [bar:/]
>> me = rw
>>
>> [blort:/]
>> me = rw
>
> The Apache conf.d/subversion.conf says:
>
>> <Location /svn>
>> DAV svn
>> SVNParentPath /var/lib/submin/svn
>> # removed GET from LimitExcept to prevent casual browsing
>> <LimitExcept PROPFIND OPTIONS REPORT>
>> AuthType Basic
>> AuthName "Authorization Realm"
>> AuthUserFile /etc/svn.auth
>> Require valid-user
>> </LimitExcept>
>> </Location>
>
> and svn.auth specifies a username:encryptedpassword pair for each member
> of [groups] in the usual way.
>
> 1. Browsing with a web browser causes a prompt for the username/password
> as expected.
>
> 2. An svn ci operation works fine.
>
> 3. An svn up operation fails, and always causes an E220000 error.
>
> 4. Replacing the GET in the LimitExcept config allows svn up to work
> without error, but allows casual browsing of the web interface.
>
> 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. 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.
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. The interaction with the client hasn't changed
the behavior even with this setting so the user making the REPORT request is
still anonymous.
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.
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. 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).
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>
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.
Technically you don't need the AuthzSVNAccessFile either, 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. 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 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.
I'd strongly urge a careful reading of:
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz
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.
Received on 2013-12-02 00:15:30 CET