Permission issues with static generated files in pub directory

[miguelbalparda]

We have been experiencing issues with permissions using the latest version of Magento 2.

It seems that it all comes from 'vendor/magento/framework/Filesystem/DriverInterface.php' which explicitly sets the umask for folders to something that isn't going to work on a lot of setups, including our own.

Is there any reason for not setting the default for directories to 0755 instead of 0770?

Our issues were mostly 403 errors inside the pub folder for assets and templates and we suspect a lot of hosting companies might face this issue too.

[mazhalai]

Hello @miguelbalparda, did you create a group as recommended? http://devdocs.magento.com/guides/v2.0/install-gde/install/file-system-perms.html

[miguelbalparda]

@mazhalai yes, we tried that. Please keep in mind this is not me as an individual but a hosting company. It also looks like we are not the only one facing this issue https://twitter.com/mbalparda/status/667029022099046400
Is there any reason in particular to use 0755 instead of 0770?

[piotrekkaminski]

@miguelbalparda can you provide more details on the setup and why you think it fails? Are the newly generated files not getting proper permissions?

[vancoz]

@miguelbalparda we changed it from 755 to 770 because we would like to close access to anybody except file owner and group. Php files can contain configuration settings, keys, etc... so it is better to keep it safe.

Please follow the instruction to set correct ownership setting http://devdocs.magento.com/guides/v2.0/install-gde/prereq/apache-user.html#install-update-depend-user-group

Thank you

[buskamuza]

Just to clarify: we recommend 0770.
The reason:

• we want the owner to have write permissions. The owner user should be used for CLI commands/operations on the application. It may include necessity to modify files
• we want the group to have write permissions to some folders. A user in the group would be the web-server user, so Web Magento application could modify necessary files (e.g., cache)

[miguelbalparda]

Adding a bunch of users to the apache group is less than ideal, as it may cause security concerns on shared platforms and in some cases it is even impossible to implement. We will investigate more about adding apache to the users group since it might be the solution.

[robfico]

The issue we see is in shared hosting where groups and ownerships cannot easily be set up in the desired fashion. With php-fpm, PHP runs as the owner. Apache runs as another less privileges user (i.e. nobody, apache, etc...). Apache can not "out of the box" pull css, js, and images (essentially static resources) from pub/static/xxx. php-fpm can read any file the owner has read permission on, so no issues with the php files themselves not being world readable.

If we add the user to the nobody group, or nobody to their group, it does work, but it alters the standard way for shared hosting, and may open up security issues. As Miguel mentioned, we added the apache group to the user's group, and that seems to work. However, this could lead to other issues if a perl/cgi based script were to be used.

[miguelbalparda]

+1 for the setup @robfico described.

[piotrekkaminski]

so @miguelbalparda @robfico would it be the right solution for you to have only the generated files (js/css/images) world readable (given they are already being sent outside, not a security issue)? and the code (including generated) could stay as is?

[miguelbalparda]

@piotrekkaminski yes, that seems to be a solid solution. So far we haven't seen a single issue with files/folders outside the pub folder.

[robfico]

Yes, I think that would work well. Since those files are publicly viewable anyway on the web, they should be world readable and directories world executable permissions wise to match. This way Apache is unrestricted in its static content access, while php-fpm can be used to manage access to mroe restricted files (xml, php, etc...). Seems like a win-win, and will avoid issues with other standard hosting in the shared world.

[lngla]

After installing Magento 2 with data and running the content deploy, all permissions on those files were created at 770 & 660. None of the content was viewable for me, including the css and product images. It took me awhile, but once I figured out to change permissions to 755 and 644, my css and images were loaded and visible. I am continuing to have this issue- every time I add a new product image permissions are pre-loaded to 770 and newly cached images both appear broken.

I would love to see the solution talked about here.

[miguelbalparda]

We started experiencing errors in the vendor dir too.

[20-Nov-2015 14:22:42 America/Detroit] PHP Fatal error: require(): Failed opening required '/chroothtml/vendor/magento/module-media-storage/registration.php' in html/vendor/composer/autoload_real.php on line 59