Re: How to prevent casual browsing
On 1/1/14, 11:55 AM, Peter Flynn wrote: 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. This is actually really old behavior. OT but I can't see why the REPORT request didn't need authentication; but it's moot anyway. Because the LimitExcept included REPORT. At that point it would seem that it ought ask my client to authenticate, and it would prompt me for the credentials. Agreed, I've started working on fixing that, but found there are an awful lot of places where it needs fixing. So I haven't finished yet. We have a long standing history of not necessarily returning the proper HTTP result code. 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. /etc/svn.auth was the username/password map for Basic authentication. Doesn't matter what you call it. 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/y' svn: E175013: Access to 'http://xxx.xxx.xx/svn/y' forbidden If I comment out AuthzSVNAccessFile, I still get $ svn up Updating '.': svn: E22: Not authorized to open root of edit operation However, if I also comment out the SVNPathAuthz short_circuit line, it all works correctly. If you don't remove the LimitExcept block you're going to still have those sorts of problems unless you set SVNPathAuthz off which I wouldn't recommend. Once you're removed the LimitExcept block (making your config similar to the config I posted), then you can start potentially removing AuthzSVNAccessFile. Thank you very much indeed for the comprehensive explanation and a working solution. Sure.
How to prevent casual browsing
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: E22: 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 E22 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 E22 error? ///Peter
Re: How to prevent casual browsing
On 2013-12-01 15:39, 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: E22: 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 E22 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 E22 error? You do not have AuthzSVNAccessFile $path/to/authz in your Location config. -- olli
Re: How to prevent casual browsing
On 12/01/2013 04:51 PM, olli hauer wrote: On 2013-12-01 15:39, 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: E22: 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 E22 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 E22 error? You do not have AuthzSVNAccessFile $path/to/authz in your Location config. I'm sorry, I omitted to say that the submin installation included an apache-svn.conf which is soft-linked into the httpd/conf.d directory, and that *does* include the AuthzSVNAccessFile /var/lib/submin/conf/authz line. This is the default for submin. IfModule mod_authn_dbd.c DBDriver sqlite3 DBDParams /var/lib/submin/conf/submin.db IfModule mod_dav_svn.c Location /svn DAV svn SVNParentPath /var/lib/submin/svn AuthType Basic AuthName Subversion repository # Authentication AuthBasicProvider dbd AuthDBDUserPWQuery SELECT password FROM users WHERE name=%s # Authorization AuthzSVNAccessFile /var/lib/submin/conf/authz Satisfy Any Require valid-user /Location /IfModule (and mod_authn_dbd is included in httpd.conf). Is this Location conflicting with the one in subversion.conf, and which one should take precedence? ///Peter
RE: How to prevent casual browsing
Hi Peter From: Peter Flynn Sent: Monday, 2 December 2013 1:40 AM 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. Are they separate projects or separate accesses to the same project? You know, of course, that you can set up authz privileges to specific subdirectories? 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: E22: 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. Not sure about this one. Currently the svn/conf/authz file says [groups] dev = a,b,c,d,e,me [foo:/] @dev = rw [bar:/] For the private one, try adding the following line here: * = That turns off read and write access for everybody EXCEPT the explicitly-named members. At least, it works that way for us. 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 E22 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 E22 error? -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
Re: How to prevent casual browsing
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: E22: 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 E22 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 E22 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
