Incorrect permissions for var directory

[MicWit]

When using Apache for the web server, the var directory should have 777 permissions (this is default in a symfony 4 website-skeleton) so that the cache directory can be created etc. This is not set in the demo application (no write for other users) and is an issue, as composer does not use the www user to create the site.

[jkufner]

the var directory should have 777 permissions

Not true. The directory must be writable by the web server, but it should not be writable by everyone, so attackers cannot use such a directory to store a rootkit.

[MicWit]

If that is the case, the default project is configured incorrectly.

[javiereguiluz]

Not sure what to do here. First, we use the exact same code as Symfony Skeleton to create things (the calls to the umask() function). Second, this project is a bit special, because it has to work out of-the-box without doing anything, configuring anything or running any command.

@MicWit could you please create a pull request with the changes you have in mind so we can see if they are compatible with the goals of this project? Thanks!

[stof]

Well, do we still have the page in the symfony doc about the permission setup (using ACLs and so on) ?

[javiereguiluz]

We have the page, but the contents are very different:

• 4.x: https://symfony.com/doc/current/setup/file_permissions.html
• 3.x: https://symfony.com/doc/3.4/setup/file_permissions.html

[stof]

I think we should still have some doc section about file permissions for cases where they still need the cache to be writable (the small note says it might happen, but does not give the proper instructions)

[MicWit]

I have looked further into this. @javiereguiluz, I can not work out how to create a pull request. GIT doesn't see changes in permissions for directories as it doesn't see directories, only files. Basically, if you look at the difference between the demo app and the symfony-skeleton, ./var and ./var/log should be set as 777.

This is because when you do a composer install, you are doing it under the username and group that you logged into the operating system as. When Apache runs the app (and creates the cache if in dev), it is run under the www-data (or sometimes just www) user and group. This means that when you run the app under an Apache server, it will fail as it can not write the cache.

I would argue that if you want this demo to run out of the box, you should also include instructions (and update permissions) to get it to run under Apache as well. To get it up and running at the moment, as an example I would do:

composer create-project symfony/symfony-demo demotest
cd demotest
chmod 777 var/ var/log/
composer require symfony/apache-pack

Now this will work IF apache root (or apache virtual host root) is set to the ./public/ directory (this worked even if you just called the .web/app_dev.php file in Symfony 3.x) and this is because of Webpack Encore using absolute paths and not relative paths like assetic used.

This demo is supposed to show someone who is looking at moving to Symfony as to what it can do. A lot of these users will be on Apache servers (in reality your not really going to run the internal server in prod most of the time), and so will test this on their a Apache servers. Its not a good advertisement if it comes up with errors immediately with no instructions on how to fix them, I think this should be addressed in order to stop potential users of Symfony from being turned off it at first glance.

As far as the issues go with having the var directory as 777 being used by attackers as a place to store a rootkit, this directory is below the web root, and if you have someone logged onto your unix system as any user, they are going to be able to write to some place, so I don't see this as a huge issue (not being accessible via a browser). If this is not the case and it is an issue, then the main Symfony project has this issue.

[jkufner]

The attacker don't have to be logged in as a user. He may use some security hole to write a file somewhere and then somehow execute it. If he cannot store the rootkit file, it is much harder to create a backdoor. Therefore, setting 777 permissions is bad practice and it is bad idea to encourage such a behavior.

[MicWit]

1. If not logged in they would not be able to write a file there (as its below the root dir)
2. Even if they could get a file there how could they possibly execute it if they aren't logged in? There is no web path that could get them there.
3. I there was a way they could get there and could execute it, this is a major security issue in the website-skeleton that needs to be fixed.

To proove that, just do 2 new composer projects, one of the demo and one of the website-skeleton (the most common way to set up a Symfony project) and check the permissions on var and sub directories and compare.

Unless you have control over user account management at an OS level on all environments (which you wont if any are in a cpanel account that you dont have back end access to) the var directory will HAVE to be 777 or it will not work with Apache. I think there needs to be more documentation on the Symfony site about the setup of Apache for Symfony (and Symfony for Apache). I may look at creating a tutorial for the setup of Symfony 4.x in Apache in Ubuntu if Symfony want this in their documentation.

[EmilCataranciuc]

@MicWit @jkufner is correct. Setting file permissions to 777 on Linux, to any file or directory is considered poor practice. That's 101 of Linux security.

[javiereguiluz]

Let's close this super old issue and let's hope that Symfony Docs is enough to fix situations like these. Thanks.