Logs, Sessions & File Permissions

Let's tackle one of the most confusing things in Symfony: how to handle file
permissions for the cache directory.

To get our site working, we're setting the entirevar/ directory to 777:

49 lines ansible/deploy/after-symlink-shared.yml

... lines 1 - 40

- name:Setupdirectorypermissionsforvar/

file:

path:"{{ release_var_path }}"

state:directory

mode:0777

recurse:true

# We need it because logs are symlinks now

follow:yes

This includes cache/, logs/ and sessions/.

This is a bummer for security. Here's my big question: after we deploy, which files
truly need to be writable by the web server?

Let's solve this ancient Symfony mystery. To start, instead of setting the entire
var/ directory to 777, let's just do this for var/logs. This is actually the
reason we originally created this task: our site was failing because var/logs wasn't
writable.

But first, back in deploy.yml, create a new variable: release_logs_path set to
{{ ansistrano_shared_path }}/var/logs:

56 lines ansible/deploy.yml

---

- hosts:aws

... lines 3 - 14

vars:

... lines 16 - 17

release_logs_path:"{{ ansistrano_shared_path }}/var/logs"

... lines 19 - 56

ansistrano_shared_path is a special variable that Ansistrano gives us. Thanks!

Copy that variable, and back in after-symlink-shared.yml, use it:

48 lines ansible/deploy/after-symlink-shared.yml

... lines 1 - 40

- name:Setupdirectorypermissionsforvar/logs

become:true

file:

path:'{{ release_logs_path }}'

state:directory

mode:0777

recurse:true

Oh, and we don't need follow anymore. But do add become: true. Why? The files
in this directory - like prod.log - will probably be created by the web server,
so, www-data. The become: true will allow us to change those permissions.

Ah! This is the reason why sessions are stored in var/sessions. Change that:
set handler_id to ~. I'll add a comment: this means that the default PHP session
handler will be used:

71 lines app/config/config.yml

... lines 1 - 10

framework:

... lines 12 - 26

session:

# use the default PHP session handler

handler_id:~

... lines 30 - 71

Why are we doing this? Well, PHP already knows how to handle and store sessions.
It will find a directory on the file system to store them and it will handle permissions...
because making them 777 isn't a great idea. In fact, this will be the default setting
for new Symfony 4 projects.

Go back to the local terminal. We just made a change to our code, so we need to
commit and push:

An even better session setup - especially if you want to move servers or use multiple
servers - is to store them somewhere else, like the database or Memcache. You can
find details about that in the Symfony docs. That's what we do for KnpU.

Ok! Let's try it again.. refresh! It works! OMG, it's alive! So... does this mean
that the var/cache directory does not need to be writable? Well... not so fast.
Go back to the server. Move up a few directories and into current/. Check out the
var/cache/prod directory:

ls -l var/cache/prod

Woh! The cache files are writable by everyone! And so of course the site is working!
But... we didn't set the cache directory to 777 in our playbook? So, what's going on?

We still have two unanswered questions. First, why the heck is var/cache/prod/ writable
by everyone? And second, if we make it not writable, will our site still work?