What is that webserver user? On VPS/Shared environments with control panels, the control panel user owns the folders where OJS is running. You reference myuser:www-data but that is not a user on many of these system. Does Apache run under the root user? There is a level of abstraction that is not clear here. How do you determine which users exists and who is running apache, the local user, web users, etc.
In a dedicated environment, your web process is typically spawned by the root user, but then runs as a daemon user. For example, in RHEL environments, this will be the user “apache”; in Debian environments, it will be the user “nobody”. Files written by (and writable to the webserver) will typically be owned by “apache:apache” or “nobody:nobody”. In a shared VPS environment, with the webserver “running as setuid”, the user will probably be the control panel user, e.g.: “user1234:user1234”. In each case, the user probably has a group dedicated to the user, with the same name, hence the duplication after the colon in the ownership. The best way to identify the user and group is to check an existing file you know was written by the webserver, or by asking your system administrator or hosting provider.
From a system architecture standpoint you want OJS data files outside the public_html (web facing) folders so that data is protected. That said, who should have rights to that folder? The user for that hosting account? A web user (and how is that different from the hosting user?) Root? So how do you set those so that you can ensure the OJS program can read/write that but webusers cannot?
The webserver user should have read and write permissions to the OJS data files (
files_dir). What you want to prevent is direct access to this files via a URL. The distinction is that the webserver can read and write the files outside of the webroot, but because the files are outside of the webroot, no one can directly access them.
Then we have the issue surrounding uploads and walling off that folder…where ever it is so that bad files can’t get shoved onto the server and/or executed in any means. It seems that wants to be write but not read and not execute? But who has access to that folder? Only OJS.
You could leave the files in the webroot and be technically secure if you prevent the webserver from executing the files. This is complicated and you really need to know what your are doing in this case, because “execution” can take many forms, beyond just PHP execution. Files left within the webroot, but not executable, would also be exposed publicly on the internet, which means that people could access your submissions, published or unpublished, if they knew the right URL. This is another reason that placing OJS data files in webroot is not recommended.
Is this problem compounded by tools like the crossref tool that wants write access to its folder?
Processes like Usage Statistics and CrossRef should also run as your webserver user. This will happen automatically if you use the acron plugin. If you setup a cron job, be sure to setup the cron job under the same user which runs the webserver process.