From dev-return-38108-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Mon Jul 30 03:07:38 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id E4FF118065B for ; Mon, 30 Jul 2018 03:07:37 +0200 (CEST) Received: (qmail 317 invoked by uid 500); 30 Jul 2018 01:07:36 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 307 invoked by uid 99); 30 Jul 2018 01:07:36 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2018 01:07:36 +0000 Received: from [172.23.17.71] (89-233-126-4.dynamic.t-2.net [89.233.126.4]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 27552248 for ; Mon, 30 Jul 2018 01:07:34 +0000 (UTC) Subject: Re: authz changes between 1.9 and 1.10 To: dev@subversion.apache.org References: <87pnzi6p2f.fsf@codematters.co.uk> <871sbs6z1p.fsf@codematters.co.uk> <00e563bc-6fb4-1f20-f12c-9083aa73937c@apache.org> <87o9epd0bh.fsf@codematters.co.uk> From: =?UTF-8?Q?Branko_=c4=8cibej?= Openpgp: preference=signencrypt Autocrypt: addr=brane@apache.org; prefer-encrypt=mutual; keydata= xsFNBFG3qpMBEACi+jRQDd2TiYeAxVgrLZ3cyyuGOFSMh4nCyUOG9BwXC69cDLH48RcE0Mpu TFTGlfdokz6JgLKU3uqShPXiflrL6JIVnJX4rTEKRzFNkcS6Zq0PfNRnFnkwiD2KIzyAG8XE y0c1Bt7hqZ5dfXaC1b7Xo+1cnlqjdLAOnr1ruTrtfQ5sO81p9jYtARVa+iVmf8bs/FvC9Yn2 QtEDtuUfUUHx2bnB9vmh8tOjErfIcWtzCPt8uTUkmiszlkRMiB5/X97oqXlX/5dSQWE9m4M5 6Fc9ixIrmCwkF515RLrCNTv/YAtmpu4VaB0rxgTuSku0cVk83xSMrH2hNFx1fAeYBZpwp2GL ONlTy3D2N+BjWXjEUE9baGOoYM7QUbAdj4JMstSByppaAi4AiG9+raxknTWtWt2IT9LHW7Pu i6S3k4WL5jmTdQKqNQ9/+vRqiSVsA98yHQLa+s19IYh4F7WIfo2lzBAn06HEntpKS9TtV20o JyMBLOVqQP1dARWRfB0xIxGtbI61CfjEhCeG8H+UynCrHkUxgUoKsXXkI/JxsIMZ3TivFj3U MJVur7KVwg/isqqaEyMfUnCrXJxexZp8kuTjkzzvDKfYs0vHJezPQYhlqBLkK2w9VzktGjA7 lb+TO69bEyPOcBjVsCtrdYVc442/Z37G+1UV5+1X06m14Pt9UQARAQABzSBCcmFua28gxIxp YmVqIDxicmFuZUBhcGFjaGUub3JnPsLBegQTAQoAJAIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgAUCUbetMwIZAQAKCRAbymWGo0eUP2tOD/9KOLYfxwTcGV/Nj3lnKE4Y4gRl0r4cfnWm 1/2KyPYVsmQ8vWRUZxjuVHAvZrAkTBvlu+CVzrCWEEpCzQC/jki0xkPQchTEU2XOHQ6PzkXB 17o1NSSu/vyKynh0pXMRTHm4wZodzUw/tHn/Ism5QyRyhlYUP4mVX8v2hbN+stkJHrkdVBPm FspnFidhulUP5hr+LWz2qd+Ab8MOn3+x25jsGE8yaUiqmNdrmq/trvHPGThySa4Hz0uEkhfP K2knc6PpV5GTbeRn/J1eu17xVgXYVgko35Qwz5s/LRat+5R79tgBAL9SKFybCVBPr6/1Zp4u w9b0NcHW6t3aQHCxv8iEqxrJ7UIDhh/hXh4no0vzpPR1Cgjn6fK997WrpUyaAtlnbSH5QGad YY9rpFka3o2Gj+f+cr75hq6c7DnNJo94eGw9L0JEjfgordi8UkWErGOklnGf8N8brlVG0TdW 7KOz60m1E3UzIwd2lQd9a0zd8Mqrmn2MMPdJt4EpKQWaJsoK+FOdEBX0Ezm3StEXufe1IOG9 DihVcOnsx/G6aTS9GyKjURVt0jDB4wsVSzsRHYHmQpw7/ekvHFNKZS5yMNwSt2X/Szmk4GmV 69gaI79kf8VD87xwE31p0s0uVIVp7MTOTEYT5HUh5Rz6Rr66+vg9qgN1enMj5sh4f8krXgRR wM7BTQRRt6qTARAAnxIdGqDTC2FU9AE2ElT/m/Hs/57BwqUUb8qod3mJ6Qkp7PpHCBnvtbwm krrCsJl5rR1fliton6qoJUNCSfmcfeujcU8Be+q75rNZxIWi6AjMmyrjyMp9JIO7g/7+VYmL dm9c1wRn4QDnIKxl7qMPz9q8/OF6BGEMEW4zRL8rHvM7CCapOikHUKKq7GnZMVyYbue6KUTA Tczxjt6E9Av1QDnnW9zbW56jqUKdgpNek/bSTuef2xYEDzIzFPQREyw8E/C3xx8zZfOJ0+XV s1n39GLp3vugP5IBNE2pgqcyFtKISj1pVJgDr7zXjD92ZGS8xgqDxePTuf1LcCwd65BJNVVK IFsFicvBVhdslCZ7l8jkCuZAzYoFJZthUKuuJg1n7HYi8XLifZmun9Z3fbM5gk9/vA1rXsWt An597BACKDUkWA5tOb3Si4/MaRDiZYvzplHGc4sTn4aBIj3VFGGFNlOUPFLWjZLHdudNOBGj 3eIlz/DQZh/mwNGn5g98c3xehHnWxcXa0PsN2Xl1iRM2dec8drEVVRYaWPcOmGhKfqnlwl2z OeuST2TMcWhxKshVimR9eSt5pX1oGOD9PZ9V0gQDIr4d35UjQaW5ABCWbgTd7e3yPTlHoWx4 qyv+YoxEf6AlQ4nvE+q1s4wRBs/eNVQsROnYmhKhYPZUsDE6EocAEQEAAcLBXwQYAQoACQUC UbeqkwIbDAAKCRAbymWGo0eUPwd6D/92i5LBHSluiBdnzYH3kYlkIMjhy3lcqtxb/TWV1X/z CVpaZkEXvL9NQ44ZqfiOFB8fnaJvy+9rfIL3MwHKLVHOjsurBRP2DJ8H/EI6QuZV//Nxh66A dicXlE5SSiKQ5KcIH+eqZHa4XjVeXGeNZummrlhOv3ItKXETVhh2qeIQ/7zCjuw5rQk606+2 isg6cs4Nwtie1rXQ1KFtkTNQqWfqyM4PrEP9Bq5pWBQVkcxDsxk1Yj3A8L80IY3Hzwm8nRlq F+HkD/0IPgHICVDyiOB4XZtqVk+DHNOolCcdrFSXOcwt+qwD5zk4p0hdHKHagAPGBDXS8shm k2vaUDbKMUoVDdj579Jtp4tNOoVEEqqXspT995w7+ckbHGoQhFlSxCwtaXCr/8wwdwcCA2eO w0aLYrU04EbnH7Ryj4aTjsBGvJdmyZQT8/lTj5VARbEkNXTdTOs61pebDliyWtcF9Uz9b44p cLNniphcBO4SP/IMlEh8pBAJ1C2QlD4G90iJ1WK0MsJsUDix9Vb5s1AE6WA/Ss1iPCOdhhif eToCAwoobIipoxUZF2ik3oESskmMDolpVBiaPaFg+YPtNp/53dLap7jBNRNgyKXaGJAZaolp L+9hCU1EOWswqusDHDFSRUuYOXfuXZJxcbQUTnhQhRbvSDy3tDMRGd252Ur1sCOU5g== Organization: The Apache Software Foundation Message-ID: Date: Mon, 30 Jul 2018 03:07:32 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87o9epd0bh.fsf@codematters.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB On 30.07.2018 02:38, Philip Martin wrote: > Branko Čibej writes: > >> It's worth working on a fix, IMO. My suggestion would be: >> >> * Keep the single-rule behaviour as it turned up in 1.10, just >> document it. It's necessary for glob rules and making an exception >> for "old-style" rules will limit the ways we can improve the authz >> system in future. Also it'd make the next point quite a bit harder. > Agreed. It is a regression from 1.9 but it's a hard error so it will > not change behaviour silently. > >> * Change the ACE override/merge behaviour back to the 1.9 way, as >> there's no reason I can think of that it could be either. > I have a patch to do this. At present I am distinguishing between glob > and non-glob rules and only apply the 1.9 way to non-glob rules. This > means that a 1.9 authz file retains the 1.9 behaviour, and that the 1.10 > glob rules retain the the 1.10 behaviour for anyone who has started > using them. But is also means glob and non-glob rules behave > differently. > > Is it better to preserve as much 1.10 behaviour as possible because > people may have started using it, or is is better to have consistency > between glob and non-glob rules? It's definitely better to have consistent behaviour across all rule types. Otherwise there'll be no end of user questions about it ... and we'll keep second-guessing ourselves, too. Also imagine this: [:glob:/path] foo = rw foo = r What are the access rights for 'foo'? It's a glob rule but it doesn't have any wildcards in the path, so it's functionally equivalent to [/path] ... but with different behaviour about calculating the access rights? I shudder to think that users would figure this out and start using the :glob: prefix to select a different consolidation algorithm. >> * #4762 takes a bit of thought. It's relatively easy to revert to 1.9 >> behaviour for non-glob rules, because it can be done at parsing >> time. For glob rules, it'd have to be done at resolve time, as >> otherwise there's not consistent meaning of exact path match. > I have a patch to do this as well, still testing. Again I am > distinguishing between glob and non-glob rules, so the inheritance only > applies to non-glob rules. And once again I wonder if it would be > better for 1.10 glob rules to change? See above. The same considerations apply. -- Brane