Revolution Directory Permissions: The Definitive Guide

So, it seems that there is no absolute list of what Revolution installation directories require which Unix permissions. This has caused massive downtime as Packages fail to load and/or install time and time again.

Can I get everyone to chime in on their own personal favourites? I'll start.

Explanation of server permissions:

1. Read == PHP Read-only
2. Write == PHP Write Access
3. Permissions are not recursive unless marked -R

• All folders Read to start with, all files Read
• /assets Write
• /assets/files Write -R (this is actually where I keep all user uploaded content)
• /assets/components Write -R
• /core/cache Write -R
• /core/packages Write -R
• /core/components Write -R
• /core/cache Write -R
• /core/model/modx Write (I found out the hard way that some packages try to install files here)

Despite having /core/packages fully writeable, I still get package download errors whereby the ZIP file downloads only partially.

Have I missed any critical directories? Have I made some security blunders? Please leave your own additions below.

UPDATE:
Thanks, BobRay, I was copy-pasting the above code from a shell script so yeah, I doubled up. [ed. note: atmmarketing last edited this post 12 years, 5 months ago.]

core/cache is an important one (you have core/components twice, so maybe you meant the second one to be core/cache).


I don't think any extra package should be installing files in core/model/modx. They should be putting their files in core/model/packagename. Are you sure they're writing to core/model/modx?

Quote from: BobRay at Apr 03, 2014, 10:41 AM

I don't think any extra package should be installing files in core/model/modx. They should be putting their files in core/model/packagename. Are you sure they're writing to core/model/modx?

I had hours of downtime yesterday after installing pdoTools, which installs the following files in /core/model/modx/pdotools:
https://github.com/bezumkin/pdoTools/tree/master/core/model/modx/pdotools

Or rather, it didn't, because I had never run MODX Revo with core/model/modx/ having PHP Write permissions. :-(

BobRay, if core/model/modx/ is off limits to packages, someone needs to make that very clear to developers. This thread is my way of trying to mark a path through the minefield of MODX permissions.

I was expressing my personal opinion. I don't know if there's an official position on this. It's always been my understanding that add-on component core files should go in core/components. I could be wrong.

Hm. Why does line 893 in core/components/pdotools/model/pdotools/pdofetch.class.php not use the "path" parameter?

Without the path parameter being set, it's looking, by default, in core/model/modx/pdotools/, and all those files do is include files from core/components/pdotools/.

If I change the loadClass functions in three places (the pdofetch, pdomenu and pdopage class files) they at least appear to work fine without the core/model/modx/pdotools files.

There's probably a better way to specify the path to the pdoTools model directory. [ed. note: sottwell last edited this post 12 years, 5 months ago.]

Already one step ahead, Susan.

https://github.com/bezumkin/pdoTools/issues/53

It looks like it's actually a 'feature'?

I see. I think...

A "feature" to accommodate the MIGx-based multilanguage add-on. Hm. So ultimately this is my fault. But that being the case, then isn't this is really an issue with MIGxML needing to be able to find the pdoTools core? Should it have been solved from the pdoTools library in this non-standard manner?

If I change the loadClass functions in three places (the pdofetch, pdomenu and pdopage class files) they at least appear to work fine without the core/model/modx/pdotools files.
1

if ($pdoClass = $modx->loadClass($fqn, 'MODX_CORE_PATH . 'components/pdotools/model/', false, true)) {

There's probably a better way to specify the path to the pdoTools model directory.

does it still load custom pdoFetch - classes then, like mmlFetch for migxMultiLang ?

I'm going to stay out of this one and let you two figure out how best to fix this issue...

Indeed. Unintended consequences. Especially when deviating from expected, standard behavior.

Like BobRay, I'm not happy with this whole business of components putting things in the MODX core areas.

Is this just to make it easier for component developers to use getService?

The getService() function also has a "path" parameter, if one component needs to load another.