X2Go Bug report logs - #1234
acl-users-allow=ALL superceeds acl-users-deny

Full log

Message #10 received at 1234@bugs.x2go.org (full text, mbox, reply):

Received: (at 1234) by bugs.x2go.org; 26 Nov 2017 06:33:54 +0000
From ionic@ionic.de  Sun Nov 26 07:33:53 2017
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 <w.moghrabi@servicemagic.eu>, 1234@bugs.x2go.org,
 mike.gabriel@sunweavers.net
References: <2074085984.30965501.1511285012453.JavaMail.root@servicemagic.eu>
From: Mihai Moldovan <ionic@ionic.de>
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"

[Message part 1 (text/plain, inline)]

* On 11/21/2017 06:23 PM, Walid MOGHRABI wrote:
> When using ACLs with the session broker, I wanted to give access to a session 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 denied
access in deny-allow mode, while in allow-deny mode; a user that is explicitly
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ïve understanding of this would be that:
  [allow-deny]: allow user if explicitly mentioned in allowed list, otherwise
allow if not explicitly denied
  [deny-allow]: deny user if explicitly mentioned in denied list, otherwise allow

Examples for [allow-deny] ("..." denotes a list *not* containing user):
  allow = { user, ... }; deny = { user, ... } => ALLOW
  allow = { user, ... }; deny = { ... }       => ALLOW
  allow = { ... };       deny = { ... }       => ALLOW
  allow = { ... };       deny = { user, ...}  => DENY

Examples for [deny-allow] ("..." denotes a list *not* containing user):
  allow = { user, ... }; deny = { user, ... } => DENY
  allow = { user, ... }; deny = { ... }       => ALLOW
  allow = { ... };       deny = { ... }       => ALLOW
  allow = { ... };       deny = { user, ... } => DENY


This is useful because it allows access in the case a user is not a member 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 "implicitly"
by code and tests, which makes it difficult to understand what is intended and
what isn't.

For instance, one test case explicitly mentions:

  [deny-allow] allow = { user }; deny = { ALL }; => ALLOW

which just doesn't make sense to me. If  all users are denied and the order 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 order,
the allow list shouldn't even come into play.



Mihai

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.