From ionic@ionic.de Sun Nov 26 07:33:53 2017 Received: (at 1234) by bugs.x2go.org; 26 Nov 2017 06:33:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=0.7 required=3.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.1 Received: from localhost (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id D8B6E5DACF for <1234@bugs.x2go.org>; Sun, 26 Nov 2017 07:33:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ymir.das-netzwerkteam.de Received: from ymir.das-netzwerkteam.de ([127.0.0.1]) by localhost (ymir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf7wSjl_WWYb for <1234@bugs.x2go.org>; Sun, 26 Nov 2017 07:33:46 +0100 (CET) Received: from mail.ionic.de (ionic.de [87.98.244.45]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 8BD8D5DACC for <1234@bugs.x2go.org>; Sun, 26 Nov 2017 07:33:45 +0100 (CET) Received: from [10.30.16.16] (178.162.222.41.adsl.inet-telecom.org [178.162.222.41]) by mail.ionic.de (Postfix) with ESMTPSA id 565284F00206; Sun, 26 Nov 2017 07:33:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ionic.de; s=default; t=1511678025; bh=wLNnA47qFvgEJJxudFDttQKPF/HXs3l6mux5JZgXyJY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=r/oEwrCQH0QuJVc7td2PZt2IxtAecJ9NoXPys5oxzkf90jlTZcVeORLmaVyZzKY/y G32YMu8Z6heFk0qyfpVcm6xoP/sLqhE4QztxBJYR3bSFY33eIZGG880O8pF/EajOvQ ArnREPRxQemKXsEX9TabnrXlU5bj3UXhJAraFcj0= Subject: Re: [X2Go-Dev] acl-users-allow=ALL superceeds acl-users-deny To: Walid MOGHRABI , 1234@bugs.x2go.org, mike.gabriel@sunweavers.net References: <2074085984.30965501.1511285012453.JavaMail.root@servicemagic.eu> From: Mihai Moldovan Message-ID: <1ff7d092-aa53-61cb-ba55-cfaeeb35f380@ionic.de> Date: Sun, 26 Nov 2017 07:33:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2074085984.30965501.1511285012453.JavaMail.root@servicemagic.eu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MbHkASHGOqnVkoWOREAqlHGOlGI4SCnER" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MbHkASHGOqnVkoWOREAqlHGOlGI4SCnER Content-Type: multipart/mixed; boundary="l2f0bbvDCe0ldnVvA1MxRhc0GTXuTEfo2"; protected-headers="v1" From: Mihai Moldovan To: Walid MOGHRABI , 1234@bugs.x2go.org, mike.gabriel@sunweavers.net Message-ID: <1ff7d092-aa53-61cb-ba55-cfaeeb35f380@ionic.de> Subject: Re: [X2Go-Dev] acl-users-allow=ALL superceeds acl-users-deny References: <2074085984.30965501.1511285012453.JavaMail.root@servicemagic.eu> In-Reply-To: <2074085984.30965501.1511285012453.JavaMail.root@servicemagic.eu> --l2f0bbvDCe0ldnVvA1MxRhc0GTXuTEfo2 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable * On 11/21/2017 06:23 PM, Walid MOGHRABI wrote: > When using ACLs with the session broker, I wanted to give access to a s= ession setting to ALL users EXCEPT some (namely "formation{1..9}"). > I tried this but it didn't work : > [...] I really have no idea what the rules are supposed to be. For users, the current rules are (simplified, the actual rules are longer= but also redundant): [allow-deny]: allow && !deny [deny-allow]: allow (allow stands for "user explicitly listed in allow list", deny stands for= "user explicitly listed in deny list".) This doesn't make sense to me. For instance, a user not explicitly listed in the allowed list will be de= nied access in deny-allow mode, while in allow-deny mode; a user that is expli= citly granted access will still be denied if it is listed in the denied list. What was the original inspiration for this? It's not Apache httpd, since that has different rules... My na=C3=AFve understanding of this would be that: [allow-deny]: allow user if explicitly mentioned in allowed list, other= wise allow if not explicitly denied [deny-allow]: deny user if explicitly mentioned in denied list, otherwi= se allow Examples for [allow-deny] ("..." denotes a list *not* containing user): allow =3D { user, ... }; deny =3D { user, ... } =3D> ALLOW allow =3D { user, ... }; deny =3D { ... } =3D> ALLOW allow =3D { ... }; deny =3D { ... } =3D> ALLOW allow =3D { ... }; deny =3D { user, ...} =3D> DENY Examples for [deny-allow] ("..." denotes a list *not* containing user): allow =3D { user, ... }; deny =3D { user, ... } =3D> DENY allow =3D { user, ... }; deny =3D { ... } =3D> ALLOW allow =3D { ... }; deny =3D { ... } =3D> ALLOW allow =3D { ... }; deny =3D { user, ... } =3D> DENY This is useful because it allows access in the case a user is not a membe= r of any list (emulating the behavior of not using any ACL for a specific user= ) and otherwise giving correct precedence to a specific list. The current behavior is not explicitly documented either, but only "impli= citly" by code and tests, which makes it difficult to understand what is intende= d and what isn't. For instance, one test case explicitly mentions: [deny-allow] allow =3D { user }; deny =3D { ALL }; =3D> ALLOW which just doesn't make sense to me. If all users are denied and the ord= er is deny-allow, why would the user be allowed, even if it's in the allow list= ? The order isn't allow-deny, so if all users are denied with the deny-allow or= der, the allow list shouldn't even come into play. Mihai --l2f0bbvDCe0ldnVvA1MxRhc0GTXuTEfo2-- --MbHkASHGOqnVkoWOREAqlHGOlGI4SCnER Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCgAdFiEEbhHQj3UzgcdE8cg8H9Yu2W4lOocFAloaYEgACgkQH9Yu2W4l OochzQ/9ELc5hipb77suEsmB3hR0sn8nJpy1rP86QiFmUCNIGw4H5RJCP1JIaTk3 D7tm902FnTQ0+w50nuCyGZlUdazuGzPwCT2fDdExoZBNgkJOLxyXs9CTyC4QPpWx ugqX1zvPRCx5DVOIY98G0WLPLShc8YoStLG2AcTy9k1C0Gj0+SbrNRwkwU1Hwuox /25KmFCpxiLbVTn+VueB7O6lya+CPNOHhJmTPTYYfaLvqICRsVgh31jN16Q8i9x1 eX3VBIW23pawSa3Rl++g5BC+FYGRc8qLow/ZO8qglmbmlN4qCcuCCnaP3XoJSJyu UnQinC33aUt3wYYvA4aNdxd8hj9sR518K+ex3QjHTE0bbpNbZzowulZU6TcfRgIV stdY1kNj2VQ1ABw7I+1li4CJbQTvO6ne827/gFOOQTGUMdKc4aekBzb/zPFyCkMq 8ob8zDmAGIQ90j1XQ6uNPMl6RK17yxqCBr7XKI0rEgypHxdsAVMMd2Y7RuK0AWgn UbavGBsQzprMV/94hFU96k6UrYf4KAkV7U4BinaEuG9I2Hynz1/kwlC81Rt6mSqh CY3T4gJ3XEAidJ4CJKZNgEvS/7sR9Jl7TUiSqxUEB6sRcOStMAacxM2OOIPr8TDw 3har1cK0J3fqeP2v+vUf6knMBucYgJiz3bmgwRBDnvV25QgMgQM= =7KYH -----END PGP SIGNATURE----- --MbHkASHGOqnVkoWOREAqlHGOlGI4SCnER--