Created logfiles are read-only for either command line user or web user
The logfiles created by the FileBackend automatically are owned by the current user running the script - that may be the webserver's user if FLOW3 is accessed from the web or another user if called from the command line. The problem is that whoever runs FLOW3 first, owns the log file and the default access rights are something like
-rw-r--r-. If the other user tries to run FLOW3, it will fail because it can't write to the log file.
Therefore we should set the access rights to
-rw-rw---upon creating the file. This should happen in the open() method of the FileBackend.
Updated by Tim Eilers over 12 years ago
- Status changed from Resolved to New
Setting the access right to
doesn't solve the problem.
Imagine the following situation:
Webserver User = www-data
CLI User = johndoe (Group users)
Assuming the setfilepermissions.sh script has been run.
Web call first¶
Now FLOW3 will be called by Web (f.e. the Default View) at first. The Logfile is created for the used context (lets assume Production). Then the permission will look like this (not a full ls -al, i am just typing the needed data):
-rw-rw---- www-data www-data FLOW3_Production.log
Now FLOW3 is called by CLI by johndoe. You will get an exception, cause johndoe is not allowed to write to the logfile.
CLI call first¶
In this case FLOW is called by CLI first.
The permission will look like this:
-rw-rw---- johndoe users FLOW3_Production.log
Now a FLOW3 web call will fail, cause it can't write to the logfile.
special case: CLI user is root, not johndoe¶
Then CLI will never have a problem, cause root is allowed to write to the logfile even if it belongs to www-data. But Web will have a problem, if FLOW3 was called by CLI first, cause the log belongs to root and will not be writeable by www-data.
- chmod the Log Directory to 777 -> from a security view very bad!
- set SGUID for Log Directory -> if CLI is called first the logile will look like this:
-rw-rw---- johndoe www-data FLOW3_Production.logBut the problem still persists if the Web call was first, then CLI under johndoe will fail. (But not when CLI user is root. So this could be a good solution if the CLI user is root everytime. But i think the solution at the bottom is more "universal"
- precreate the Logs with the setfilepermissions.sh script -> bad, cause there could be other contextes or other logfiles later
final solution suggestion¶
- predefined seperate log directories for Web and CLI
- both dirs will be set to webserver user by the setfilepermissions.sh script -> change the script to set the owner/group of CLI log directory to the user running that script (because he will mostly be the user running CLI calls later)
- change the Logging Framework to use the seperate log directories depending on the "context" (Web or CLI)
- remove the chmod 660 again or change it to 640 or similar (at least remove the group write permission)
There will still be a problem if the user who uploads / creates / extracts the FLOW3 distribution + runs the setfilepermissions.sh script and the user who runs CLI requests later will differ. (f.e. script user = root, CLI user = johndoe).
I think this should be covered in the documentation where CLI requests are explained. In my opinion there are not most cases where that happens. Often CLI's are used at root and if it is another user it is often the one who uploads the distribution and runs the script.
Updated by Tim Eilers over 12 years ago
- File patch3513_distribution.diff patch3513_distribution.diff added
- File patch3513_flow3.diff patch3513_flow3.diff added
Please check the attached patches. I don't wont to commit them by myself (and i can't, cause i only could do it for the package but not for distribution).
I also didn't know how to show directory diffs. So you have to create Data/Logs/Web and Data/Logs/CLI in the distribution.
The idea behind it:
I did not put the SAPI name into the Log File path or something else, because it could be something like "apache2handler" or "cgi" (see http://de.php.net/manual/en/function.php-sapi-name.php and i think that is not very intuitive. So all requests coming from the web are collected into the "Web" Folder.
Perhaps this is not the final solution but an idea how to solve it...