Bug #3513

Created logfiles are read-only for either command line user or web user

Added by Robert Lemke about 12 years ago. Updated over 10 years ago.

Must have
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Has patch:


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

. 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

upon creating the file. This should happen in the open() method of the FileBackend.


patch3513_distribution.diff (1.66 KB) patch3513_distribution.diff Patch file for the FLOW3 distribution Tim Eilers, 2009-06-01 17:57
patch3513_flow3.diff (4.19 KB) patch3513_flow3.diff Patch file for the FLOW3 package Tim Eilers, 2009-06-01 17:57

Related issues

Related to TYPO3.Flow - Bug #3534: File permission issuesResolvedRobert Lemke2009-06-02


Updated by Robert Lemke about 12 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Applied in changeset r2459.


Updated by Tim Eilers about 12 years ago

  • Status changed from Resolved to New

Setting the access right to


doesn't solve the problem.

Imaginary environment

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.

solution ideas

  • 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.log
But 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 about 12 years ago

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...


Updated by Robert Lemke about 12 years ago

  • Status changed from New to Accepted
  • Assignee set to Robert Lemke
  • % Done changed from 100 to 50

Updated by Robert Lemke about 12 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 50 to 100

Applied in changeset r2517.

Also available in: Atom PDF