From users-return-26697-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Mon Jan 22 13:09:58 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 24F03180609 for ; Mon, 22 Jan 2018 13:09:58 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 15632160C4B; Mon, 22 Jan 2018 12:09:58 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5A2DB160C3A for ; Mon, 22 Jan 2018 13:09:57 +0100 (CET) Received: (qmail 86282 invoked by uid 500); 22 Jan 2018 12:09:56 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 86254 invoked by uid 99); 22 Jan 2018 12:09:55 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Jan 2018 12:09:55 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 094CD1A0B18 for ; Mon, 22 Jan 2018 12:09:55 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=6.31 tests=[RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id r9xE6QG_MmU0 for ; Mon, 22 Jan 2018 12:09:52 +0000 (UTC) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 56FFF5F2AB for ; Mon, 22 Jan 2018 12:09:52 +0000 (UTC) X-Envelope-From: stsp@elego.de Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0MC9jRt016177 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 13:09:45 +0100 Received: from localhost (ted.stsp.name [local]) by ted.stsp.name (OpenSMTPD) with ESMTPA id bcc386bd; Mon, 22 Jan 2018 13:09:45 +0100 (CET) Date: Mon, 22 Jan 2018 13:09:45 +0100 From: Stefan Sperling To: Stefan Hauffe Cc: "users@subversion.apache.org" Subject: Re: Problem with authorized user and SVN access Message-ID: <20180122120945.GW98299@ted.stsp.name> Mail-Followup-To: Stefan Hauffe , "users@subversion.apache.org" References: <80ADA1448BEC2B499FA6D6A242554CB00209F99CC8@edata03.mgm-edv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80ADA1448BEC2B499FA6D6A242554CB00209F99CC8@edata03.mgm-edv.de> User-Agent: Mutt/1.9.1 (2017-09-22) On Mon, Jan 22, 2018 at 11:39:26AM +0000, Stefan Hauffe wrote: > Hello, > > I refined my mail from 05/01/2017 and now I think there is a bug in the mod_authz_svn Module. This may allow users to see content for which they aren't allowed for. > > For the general setup, I have an Apache 2.4, Subversion 1.9 modules and mod_lua activated for authentification. The LUA-hook works for none-SVN-Locations, my user is authorized. The httpd.conf and LUA script is attached below. > > Case 1: > - The accessfile configures my user to have access on repo-root: > [repo:/] > myuser = rw > - The client (curl) shows me the repo-root but none of the files below. > - The error_log shows, that my user got authorized on root: > [Fri Jan 19 21:20:58.735108 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access granted: 'myuser' GET (null) > - But I'm not allowed to see a file below: > [Fri Jan 19 21:20:58.735706 2018] [authz_svn:info] [pid 3465:tid 140589093869312] [client ::1:59812] Access denied: - GET repo:/muhmiau.txt > > Case 2: > - The accessfile configures everybody to have access on repo-root: > [repo:/] > * = rw > - The client (curl) shows me a repo-root and the files below. > - The error-log tells, that my user is allowed to see the root and the file: > [Fri Jan 19 21:26:03.803831 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET (null) > [Fri Jan 19 21:26:03.806508 2018] [authz_svn:info] [pid 3425:tid 140589085476608] [client ::1:59814] Access granted: 'myuser' GET repo:/muhmiau.txt > > Case 3: > - Now I have an accessfile, which allows everyone to rw, *but not my user*: > [repo:/] > * = rw > myuser = > - The client (curl) shows me the full repo content > - The error_log tells, that my user is allowed to see the root and the file: > [Fri Jan 19 21:29:57.383442 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: 'myuser' GET (null) > [Fri Jan 19 21:29:57.385402 2018] [authz_svn:info] [pid 3426:tid 140589085476608] [client ::1:59816] Access granted: - GET repo:/muhmiau.txt > > That raised several questions: > 1. Why is my user not "known" for a special file in Case 1, when it generally works? (Case 2) > 2. Why does the restriction of a right (Case 3) does not lead to a restricted view? As you can see in the log, the user is not known (like Case 1). > > For me, especially Case 3 looks suspicious. > > Any help would be appreciated. This is a common misunderstanding. The behaviour looks strange but it is the result of the fact that per-path permissions in authz rule sets are combined in a logical OR fashion, rather than logical AND. Your interpretation of what your ruleset number 3 means assumes logical AND. In fact, access to the path / is granted because 'myuser' is matched by '*': [repo:/] * = rw # grant access to anyone myuser = # OR don't provide access to this user (has no effect) This is hinted at in the svnbook at http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html#svn.serverconfig.pathbasedauthz.groups "Another important fact is that group permissions are not overridden by individual user permissions. Rather, the combination of all matching permissions is granted." Where in your example '*' acts like a group which contains all users. One solution to this problem is to define a group which includes everyone except 'myuser' and then use give access to the root path to this group. By the way, you can use the 'svnauthz accessof' command to test your ruleset.