Dear everyone,
I have been searching this subject for a few days but could not get a straight forward answer.
While installation of OJS, the permission of config file, Public folder and chache folder is set to 777.
What should be the permission of these files/folders once the installation is complete.
Regards
@anupent
There isn’t a straightforward answer because so much depends on your hosting environment. Start with your hosting provider’s documentation and support, or with your system administrator, and with the following instructions:
In general, you want your permissions set such that your webserver can read and write (recursively) to config.inc.php's files_dir, and to ./cache/, and ./public/. Optionally, for added features and reduced security, you can enable write to config.inc.php, to ./plugins/ and perhaps to the locale .xml files. Your webserver should have read-only access to all other files and directories distributed in the package.
In Linux, permissions are based both on a numeric access control mode, and on file ownership. Understanding this permissions scheme is a prerequisite.
For example, ownership of apache:www with permissions of 750 (rwxr-x---) means that the apache user can read, write and execute; anyone with the www group can read or execute; and the file is protected against access by anyone else. Note that “execute” means two entirely different things for directories than for files!
Generally, the ownership of cache, public, and other web-writable directories should be your web user and the web-user’s primary group, for example apache:www-data. Permissions should probably be 750.
The ownership of the other non-web-writable directories should be your user, with either the web user’s group, or with public execute permissions. For example:
myuser:www-data with 750
or
myuser:ourgroup with 755.
Web-writable files would be the same, but without the execute permission:
apache:www-data with 640
Non-web-writable files would be perhaps:
myuser:www-data with 640
or
myuser:ourgroup with 644
With some shared hosts (for example, if your only access is via CPanel or a similar web-based admin tool), you may not have the ability to change the file ownership, and your webserver is effectively running as your user. In that case, you may still have the ability to protect your files by making them non-writable by your own user (even though this sounds counter-intuitive). In a shared host, you will almost certainly want to deny world permissions to your files, but look to the documentation and support for your host in particular.
Hi all,
See also the FAQ Entry in the wiki about file permissions.
[Edit: here is an active link from the Wayback Machine: PKP Frequently Asked Questions - PKP Wiki]
Regards,
Alec Smecher
Public Knowledge Project Team
Hello, Permission my directory sdh i replace 777 all … but still can not upload image or logo,
Please guide me
Thanks
Hi @taufiq,
Note that 777 permissions can be useful for debugging, but they are never safe to use.
It’s likely that you’re running into a problem with OJS being unable to identify file types. Search the forum for the error message you received; there are lots of threads with suggestions on how to debug/fix.
Regards,
Alec Smecher
Public Knowledge Project Team
Currently with the version of OJS 3.1 I have the same problem, can you tell me how you solved it?
Currently with the version of OJS 3.1 I have the same problem, can you tell me how you solved it?
Which server you are using Linux or Windows. When using windows sometimes there is mime type error.
Do we have an script somewhere to reset ojs’s files/folder permissions?
If not… don’t you think it could be a nice addition for our toolbox?
If you point here how the permissions need to be (I recognize I always had doubts if I’m too restrictive or permissive) I don’t mind to do implement this as a bash script.
Hi @marc,
Unfortunately between different SAPIs (FastCGI, CGI, mod_php, suexec), permissions models (Windows, standard *NIX, SELinux), and PHP configurations (open_baseurl etc), there are far too many permutations to consider. Plus a command-line PHP script vs. the web front end will often run as different user accounts. Essentially it’s up to the website’s administrator to know how permissions work in their environment and I’m not sure there’s a good alternative.
Thanks,
Alec Smecher
Public Knowledge Project Team
Then… let me focus in a very specific stack: linux (alpine) + mod_php5
I’m thinking in a script to fix issues I’m finding with the docker container I’m building.
A RTFM is much appreciated. 
Hi @marc,
mod_php is generally hard to secure because all PHP scripts run as the same user account – generally apache. A break-in in e.g. one user account’s Drupal or Wordpress or OJS installation means a compromise to all PHP apps on that system, even if they’re managed by other user accounts.
File permissions in mod_php are relatively simple, though. You generally just have to chown/chgrp everything mentioned in docs/README to apache/apache.
Regards,
Alec Smecher
Public Knowledge Project Team
As far as docker’s philosophy is compartmentalization (one dock for each app, even for each journal) it won’t be a problem. Long time ago since I open the README. Thanks.
@ctgraham
I know it’s quite an old post, but can you please clarify the difference between the permissions of web-writable files and non-web-writable files? Shouldn’t the permissions for non-web-writable files be 444? or I’m missing something?
In Linux, permissions are a combination of (at least) the file’s ownership (user and group) and the files mode (a bitmask for each of user, group, and others).
A mode of 444 means, “Everyone can read this file, no one can write to it or execute it”. This is a useful way of restricting write access to files which are owned by the web user. Beware, however, that in this situation the web user may be able to change the files mode to grant itself write access.
Alternately, in some configurations, files which you don’t want the web users to write to can be owned by a different user.
The requested URL /wiki/index.php/PKP_Frequently_Asked_Questions was not found on this server.
I have added an archived link on the post above.
Regards,
Alec Smecher
Public Knowledge Project Team
Would be good to somehow forward the old FAQ links to the according new pages.
