Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Insufficient permissions on generated CSS and JS files #1507

Closed
stefanschramm opened this Issue · 12 comments

3 participants

@stefanschramm

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

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

@mattab
Owner

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
Owner

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

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

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

@stefanschramm

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

@robocoder

(In [2660]) fixes #1507

@stefanschramm

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

@chmod($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

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

@robocoder

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

@robocoder

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

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

@stefanschramm stefanschramm added this to the Piwik 0.6.5 milestone
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.