Resource group ACLs being ignored

18 Posts

fractalwolfe Reply #1, 12 years, 7 months ago

I've set up a fresh CentOS server running Nginx, PHP-FPM 5.4.24 and Percona Server 5.6 (MySQL) and moved my MODX 2.2.11-pl install over from the old Windows + Apache + PHP 5.4.16 + MySQL Server 5.6 install (WAMP server). After a bit of work getting everything to work, upgrading MODX to 2.2.13-pl and fixing friendly URLs, I noticed everything is working, except that ACLs are being ignored. All members only restrictions I had set on the resources are completely ignored. As such anonymous users can access these pages without MODX saying anything at all. All these permissions were working fine on the Windows install.

The manager on the other hand is fine, working as it should. It's only the web context that is affected. I've tried removing all restrictions and resource groups and re-creating them, clearing cache (through manager AND manually) and flushing permissions and sessions. Nothing works.

You guys have any ideas what might be the issue?

EDIT: More testing and removing all permissions (even access to the entire web context) for anonymous makes no difference at all. This is very strange.

This question has been answered by fractalwolfe. See the first response.

[ed. note: fractalwolfe last edited this post 12 years, 7 months ago.]

24,544 Posts

BobRay Reply #2, 12 years, 7 months ago

The only thing I can think of is that all permissions are ignored when MODX is run from the command line.

Here is the xPDO code that does the check to see if MODX is running from the command line:

if (!defined('XPDO_CLI_MODE')) {
    if (php_sapi_name() == 'cli') {
        /**
         * This constant defines if xPDO is operating from the CLI.
         */
        define('XPDO_CLI_MODE', true);
    } else {
        /** @ignore */
        define('XPDO_CLI_MODE', false);
    }
}

You might try putting a tag on a page for a snippet with this code:

$output = '<br />XPDO_CLI_MODE constant: ' . XPDO_CLI_MODE;

if (php_sapi_name() == 'cli') {
    $output .= '<br />php_sapi_name is cli';
} else {
    $output .= '<br />php_sapi_name is *not* cli';
}
   
return $output;

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

18 Posts

fractalwolfe Reply #3, 12 years, 7 months ago

Tried that. The output is as follows:

XPDO_CLI_MODE constant: 
php_sapi_name is *not* cli

Running it from cli return that it's "cli" and constant is 1 (as in true).

So something is still up with this. It's weird, I've never had any issues like these when setting up permissions. Is there any way I could debug why this happens?
[ed. note: fractalwolfe last edited this post 12 years, 7 months ago.]

discuss.answer

18 Posts

fractalwolfe Reply #4, 12 years, 7 months ago

Further testing reveals that the SQL query that fetches the resource's policies fails!

This is the query that is run:

SELECT Acl.target, Acl.principal, Acl.authority, Acl.policy, Policy.data FROM `modx_access_resource_groups` Acl LEFT JOIN `modx_access_policies` Policy ON Policy.id = Acl.policy JOIN `modx_document_groups` ResourceGroup ON Acl.principal_class = 'modUserGroup' AND (Acl.context_key = 'web' OR Acl.context_key IS NULL OR Acl.context_key = '') AND ResourceGroup.document = 1 AND ResourceGroup.document_group = Acl.target GROUP BY Acl.target, Acl.principal, Acl.authority, Acl.policy

It works on the Windows machine and returns the appropriate rows. On the Linux machine however, the query returns this error:

#1055 - 'okaloite.Policy.data' isn't in GROUP BY

MODX on the other hand just returns an empty array, thus giving the user the right to access said page. Could there be something relating to Percona Server 5.6 running in strict mode causing this?

SOLUTION:

Indeed there was. MySQL in Strict mode had sql_mode = ONLY_FULL_GROUP_BY set, which caused it to complain about the GROUP BY.
Removing ONLY_FULL_GROUP_BY from set sql_modes solves the issue.

Where should I report this bug? xPDO or MODX? [ed. note: fractalwolfe last edited this post 12 years, 7 months ago.]

24,544 Posts

BobRay Reply #5, 12 years, 7 months ago

Good catch.

Where to report is a tough call. Offhand, I would say MODX, but it's up to you. Having found it, you have a better idea of whether it's in the xPDO layer or the MODX security layer than I do. I'm sure it will find its way to OpenGeek either way.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

18 Posts

fractalwolfe Reply #6, 12 years, 7 months ago

Posted the issue as MODX, since the query being run is part of modResource.

Github issue can be found here: https://github.com/modxcms/revolution/issues/11212

Answered Resource group ACLs being ignored