@stefanschramm opened this Issue on July 23rd 2010

After upgrading to 0.6.5 via web interface (and also after a new manual installation) the web interface's stylesheet is gone and "Oops problem during the request, please try again."-message appears. Maybe the priority of this bug is even "critical".

Apache Access Log says:

x.x.x.x - - [23/Jul/2010:21:11:54 +0200] "GET /piwik/tmp/assets/8c06f99faa9d140d731f08decd24e5d5.css HTTP/1.1" 403 255 "http://xxxxxxx/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100715 Ubuntu/10.04 (lucid) Firefox/3.6.7"
x.x.x.x - - [23/Jul/2010:21:11:54 +0200] "GET /piwik/tmp/assets/6af420abb70510fee98e0926d5e90f78.js HTTP/1.1" 403 254 "http://xxxxxxx/piwik/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100715 Ubuntu/10.04 (lucid) Firefox/3.6.7"
  • so a 403 (forbidden) occurs for the (generated) CSS and JS.

The directories in /tmp/ have only rwx permissions for owner:

drwx------  2 user1 user1 4.0K Jul 23 21:10 assets
drwx------  3 user1 user1 4.0K Jul 23 21:05 cache
drwx------  2 user1 user1 4.0K Jul 23 21:04 latest
drwx------  2 user1 user1 4.0K Jul 23 21:10 sessions
drwx------  2 user1 user1 4.0K Jul 23 21:05 templates_c

JS and CSS in /tmp/assets/:

-rw------- 1 user1 user1 377K Jul 23 21:05 6af420abb70510fee98e0926d5e90f78.js
-rw------- 1 user1 user1  60K Jul 23 21:05 8c06f99faa9d140d731f08decd24e5d5.css

After manually doing cmhod g+rx tmp/* and chmod g+r tmp/assets/* the web interface is working again (on my system the user apache is running as is in group user1 - thus read access for group is sufficient in my case).

Maybe the the script, that creates the files and directories, should do a chmod afterwards. (I don't know if there is a best-practise to automatically determine which would be the minimal-sufficient permissions. a+rx and a+r would be the easiest.)

@stefanschramm commented on July 23rd 2010

An addition: my system's default umask is 0027.

@mattab commented on July 23rd 2010 Member

on every page view, in the FrontController in init:


            $directoriesToCheck = array(
                    '/tmp/',
                    '/tmp/templates_c/',
                    '/tmp/cache/',
                    '/tmp/assets/'
            );

            Piwik::checkDirectoriesWritableOrDie($directoriesToCheck);

This should have triggered an error asking you to put write permissions on the directory.

The testing code is in Piwik::checkDirectoriesWritable()

Somehow I expect your directories to have is_writable() == true, but still they are not writable by the web server.

Why is that that is_writable returns true in checkDirectoriesWritable? any idea?

@mattab commented on July 23rd 2010 Member

Note that if the webserver can't write in tmp/cache/ this is pretty bad for performance, as Tracker will be doing potentially several SQL reads per page view, instead of caching in files the website data.

@stefanschramm commented on July 23rd 2010

I'm running PHP as CGI with SuExec. So PHP-scripts are executed as user1 and have full (read+write) permissions, but the webserver-user itself is just in the user1-group and thus can have other permissions to the files than the PHP-scripts.

@robocoder commented on July 24th 2010 Contributor

If php runs with suexec, what is user1's umask?

@stefanschramm commented on July 24th 2010

The umask is 0077 when testing with <? passthru('umask'); ?>.
<? echo decoct(umask()); ?> returns 77 too.

@robocoder commented on July 24th 2010 Contributor

(In [2660]) fixes #1507

@stefanschramm commented on July 25th 2010

I checked out and tested trunk - the files now have sufficient permissions, but the tmp/assets-directory still needs a chmod g+x so that the webserver is able to read files within it.

The problem is, that the permissions that are passed to Piwik_Common:mkdir when creating the directory are masked by the umask too.

When i add

<a class='mention' href='https://github.com/chmod'>@chmod</a>($path, $mode); // bypass too restrictive umask

directly after the mkdir call in line 311 in Common.php it's working. But I'm not sure if it's a good solution to bypass the umask everytime for all directories...

@robocoder commented on July 25th 2010 Contributor

(In [2669]) refs #1507 - override umask only on public folders

@robocoder commented on July 27th 2010 Contributor

(In [2707]) refs #1507 - add @chmod() here for consistency

@robocoder commented on August 6th 2010 Contributor

Note: we're switching to a php proxy in #1527 -- I'll revert some/all of the previous changes once the new code is commited.

@robocoder commented on September 12th 2010 Contributor

(In [3140]) refs #1507, refs #1527 - revert hack from #1507, and fix unit test on Windows per Julien's email

This Issue was closed on September 12th 2010
Powered by GitHub Issue Mirror