package: x2gobroker priority: normal tags: patch
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 :
================================================= [TRAVAUX] fullscreen=true clipboard=none name=TRAVAUX host=tce-server (10.10.10.1) acl-users-allow=ALL acl-users-deny=formation1, formation2, formation3, formation4, formation5, formation6, formation7, formation8, formation9 acl-any-order=deny-allow
I played with many settings, changing order, using only the "acl-users-deny" option, ... none of them worked as expected.
I ended in thinking that there was a bug with acl-users-allow=ALL which was taking over any other setting.
I did a little fix that seem to work, at least for this use case.
Regards, Walid Moghrabi
TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
- 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
-
Mihai Moldovan -
Walid MOGHRABI