From dev-return-38639-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Sun Dec 2 17:23:10 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 075FF180609 for ; Sun, 2 Dec 2018 17:23:09 +0100 (CET) Received: (qmail 16039 invoked by uid 500); 2 Dec 2018 16:23:09 -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 16029 invoked by uid 99); 2 Dec 2018 16:23:09 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Dec 2018 16:23:08 +0000 Received: from [172.17.13.7] (unknown [77.234.149.122]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 819D13C0E for ; Sun, 2 Dec 2018 16:23:07 +0000 (UTC) Subject: Re: authz changes between 1.9 and 1.10 To: dev@subversion.apache.org References: <87pnzi6p2f.fsf@codematters.co.uk> <5b5abe99-e823-731d-877a-300f0a71c49b@apache.org> <855c352e-f68b-f5d1-5d66-9cfc5a6dcddf@apache.org> <605df939-6b95-cc9d-edb1-054109992fdb@apache.org> <2b44ff26-3d52-5bd7-b0b7-8499288f1333@apache.org> 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: <39311316-2949-8767-9edd-8ffcf0b7aefc@apache.org> Date: Sun, 2 Dec 2018 17:23:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2b44ff26-3d52-5bd7-b0b7-8499288f1333@apache.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB On 02.12.2018 10:38, Branko Čibej wrote: > On 02.12.2018 08:43, Branko Čibej wrote: >> On 02.12.2018 08:25, Branko Čibej wrote: >>> On 08.09.2018 11:17, Stefan Fuhrmann wrote: >>>> These are the guiding principles for the 1.10 authz design: >>>> >>>> (1) ACLs are only evaluated on a per-user bases; ACLs that >>>>     don't mention this user (or any of their groups)  are ignored. >>>>     Rationale: We don't want to explicitly repeat inherited access >>>>     specs that don't change for the respective path / section. >>> This is not entirely true, as seen in the fix for SVN-4793. If a user is >>> "not mentioned" in an inverted selector, those rights do propagate to >>> the global level. For example: >>> >>> [groups] >>> readers = foo, bar >>> >>> [/] >>> ~@readers = rw >>> @readers = r >>> >>> >>> In this case 'user' has read-write access to '[/]' even though she's not >>> mentioned anywhere in the authz file or the specific ACL for '[/]'. >>> >>> >>>>> In 1.9 any repeat acl lines that were the exact same match, such as: >>>>> >>>>>    [/some/path] >>>>>    user = rw >>>>>    user = r >>>>> >>>>> resulted in the last line overriding all the other lines, so user=r in >>>>> the example above.  In 1.10 the lines combine, so user=rw in the example >>>>> above.  Is this a bug in 1.10, or a bug in 1.9 that is fixed in 1.10, or >>>>> an acceptable behaviour change? >>>> Ouch. That is a bad one and an oversight in the design - I think. >>>> >>>> According to (3), 1.9 behaves correctly. I guess we consider it >>>> an unordered collection in 1.10 and then a union is the only thing >>>> that approximates intent when a user is a member of different >>>> groups with different access rights. Strict ordering becomes >>>> very useful when assigning rights to groups: >>>> >>>> [/some/path] >>>> @Users = rw >>>> @BadUsers = r >>> We already have strict ordering within an ACL (authz_acl_t in >>> libsvn_repos/authz.h): >>> >>> /* All other user- or group-specific access rights. >>> Aliases are replaced with their definitions, rules for the same >>> user or group are merged. */ >>> apr_array_header_t *user_access; >>> >>> >>> >>> The "merge" semantics was intentional; if we decide it's a bug (and I >>> think it is), it's fairly easy to change. I would lean in the direction >>> of making repeating the same access entry selection a hard error at >>> parsing time. This requires changes to the merge semantics implemented >>> in add_access_entry() and merge_alias_ace() in >>> libsvn_repos/authz_parse.c. The nice part is that it would catch errors >>> like this: >>> >>> [aliases] >>> afoo = foo >>> abar = bar >>> >>> [/] >>> &afoo = rw >>> foo = r >>> ~&abar = rw >>> ~bar = r >>> >>> >>> With the current implementation we translate the ACL to: >>> >>> [/] >>> foo = rw >>> foo = r >>> ~bar = rw >>> ~bar = r >>> >>> >>> and even with strict ordering I'd say this is a bug and not intentional. >> Note that this should also be an error: >> >> [/] >> $anonymous = r >> ~$authenticated = rw > I have a patch ready, here are some examples of what it does (currently, > all these examples are valid and produce merged access rights): https://issues.apache.org/jira/browse/SVN-4794