User can login but has elevated permission for a different group

Security
1

This is driving me up the wall. It happens in my dev environment, but not production.

I have 2 user groups (besides admin & anon) Staff & Customers both with matching resource group restrictions.

If a customer from either the Customer or Staff group logs in they get access to resources belonging to Staff AND Customer (they should only have access to one resources)

I’ve downloaded the database and basically cloned the live site to dev - the only difference being the host name and environment. Everything points to a difference in the environment, but I can’t see anything that would cause such a specific issue.

  • Ubuntu WSL php7.4
  • I’m not logged into the manager in the same browser (or at all)
  • modx cache’s have been cleared (manually rm -rf cache/*) as have browser cache’s, cookies, storage etc
  • creating new users in the given groups shows no differences
  • triple checked ACL - they are correct and no different from production
  • triple checked individual resource access control. Correct and not different from production.
  • dumping the user’s session variables all checks out (correct group id and name - no additional ones)

UPDATE
Did some more testing, it turns out that ALL users have access to ALL contexts, including the manager context…

Completely baffled. HELP!!

2

If you use Chrome, install the Cache Killer extension and see if that makes a difference. Chrome is famous for not fully clearing its cache.

Make sure they’re not sudo users.

This is a stretch, but you could check to see if you local MODX is running in cli mode. That would bypass the ACL restrictions.

$cliMode = php_sapi_name() == 'cli';

It’s unlikely unless you’re running MODX from your code editor or maybe a batch file.

3

Mind if we quadruple check those for you? Can you show a screenshot of the context permissions for all usergroups (including anon and admin), and if that has any non-core policies attached also show the enabled permissions?

Assume this is a 2.8.3 install?

4

No - not sudoers, I’ve tried every browser in every incognito mode etc - even one in a x11 session …

‘cli’ mode … that is a new one on me - I would have to have managed to accidentally set that somehow.
How would I actually check that? (just echo it I suppose?)

5

I would love to, but actually just burned it all down and starting with fresh d/l files and database from production as well.

But like I said it is basically a clone of production … where there are no issues.

6

Well… duhh - if they are the same :slight_smile:

image
image1412×538 19.4 KB

image
image1740×466 18.1 KB

image
image1419×545 19.3 KB

image
image1747×517 18.3 KB

image
image1398×569 19.9 KB

image
image1127×444 13.9 KB

image
image1389×603 20.6 KB

image
image1724×601 22 KB

7

So I think I solved this without fully understanding why its working/not-working.

Initially, I had issues logging in to the manager on first setup - noticed php/modx was not writing session files to the server… did some checking and enabled php session.auto_start (wrong!)

That seemed to get things working, but that in combination with the modx session.name system setting being set to a domain name was causing the issue (of completely breaking security)

I think this has something to do with the session_name not matching the context url … ? something like that?

But what is odd (I think) is if I set the session_name (modx) to anything EXCEPT a domain name, security/sessions/logins work normally ~ as expected.