|
1 | 1 | Setting up or Fixing File Permissions |
2 | 2 | ===================================== |
3 | 3 |
|
4 | | -One important Symfony requirement is that the ``var`` directory must be |
5 | | -writable both by the web server and the command line user. |
| 4 | +In Symfony 3.x, you needed to do some extra work to make sure that your cache directory |
| 5 | +was writable. But that is no longer true! In Symfony 4, everything works automatically: |
6 | 6 |
|
7 | | -On Linux and macOS systems, if your web server user is different from your |
8 | | -command line user, you need to configure permissions properly to avoid issues. |
9 | | -There are several ways to achieve that: |
| 7 | +* In the ``dev`` environment, ``umask()`` is used in ``bin/console`` and ``web/index.php`` |
| 8 | + so that any created files are writable by everyone. |
10 | 9 |
|
11 | | -1. Use the same User for the CLI and the Web Server |
12 | | -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
13 | | - |
14 | | -Edit your web server configuration (commonly ``httpd.conf`` or ``apache2.conf`` |
15 | | -for Apache) and set its user to be the same as your CLI user (e.g. for Apache, |
16 | | -update the ``User`` and ``Group`` directives). |
17 | | - |
18 | | -.. caution:: |
19 | | - |
20 | | - If this solution is used in a production server, be sure this user only has |
21 | | - limited privileges (no access to private data or servers, execution of |
22 | | - unsafe binaries, etc.) as a compromised server would give to the hacker |
23 | | - those privileges. |
24 | | - |
25 | | -2. Using ACL on a System that Supports ``chmod +a`` (macOS) |
26 | | -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
27 | | - |
28 | | -On macOS systems, the ``chmod`` command supports the ``+a`` flag to define an |
29 | | -ACL. Use the following script to determine your web server user and grant the |
30 | | -needed permissions: |
31 | | - |
32 | | -.. code-block:: terminal |
33 | | -
|
34 | | - $ rm -rf var/cache/* |
35 | | - $ rm -rf var/log/* |
36 | | -
|
37 | | - $ HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1) |
38 | | - $ sudo chmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" var |
39 | | - $ sudo chmod +a "$(whoami) allow delete,write,append,file_inherit,directory_inherit" var |
40 | | -
|
41 | | -3. Using ACL on a System that Supports ``setfacl`` (Linux/BSD) |
42 | | -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
43 | | - |
44 | | -Most Linux and BSD distributions don't support ``chmod +a``, but do support |
45 | | -another utility called ``setfacl``. You may need to install ``setfacl`` and |
46 | | -`enable ACL support`_ on your disk partition before using it. Then, use the |
47 | | -following script to determine your web server user and grant the needed permissions: |
48 | | - |
49 | | -.. code-block:: terminal |
50 | | -
|
51 | | - $ HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1) |
52 | | - # if this doesn't work, try adding `-n` option |
53 | | - $ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var |
54 | | - $ sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var |
| 10 | +* In the ``prod`` environment (i.e. when ``APP_ENV`` is ``prod`` and ``APP_DEBUG`` |
| 11 | + is ``0``), as long as you run ``php bin/console cache:warmup``, no cache files |
| 12 | + will need to be written to disk at runtime. |
55 | 13 |
|
56 | 14 | .. note:: |
57 | 15 |
|
58 | | - The first ``setfacl`` command sets permissions for future files and folders, |
59 | | - while the second one sets permissions on the existing files and folders. |
60 | | - Both of these commands assign permissions for the system user and the Apache |
61 | | - user. |
62 | | - |
63 | | - ``setfacl`` isn't available on NFS mount points. However, storing cache and |
64 | | - logs over NFS is strongly discouraged for performance reasons. |
65 | | - |
66 | | -4. Without Using ACL |
67 | | -~~~~~~~~~~~~~~~~~~~~ |
68 | | - |
69 | | -If none of the previous methods work for you, change the umask so that the |
70 | | -cache and log directories are group-writable or world-writable (depending |
71 | | -if the web server user and the command line user are in the same group or not). |
72 | | -To achieve this, put the following line at the beginning of the ``bin/console``, |
73 | | -``public/index.php`` and ``public/index.php`` files:: |
74 | | - |
75 | | - umask(0002); // This will let the permissions be 0775 |
76 | | - |
77 | | - // or |
78 | | - |
79 | | - umask(0000); // This will let the permissions be 0777 |
80 | | - |
81 | | -.. note:: |
82 | | - |
83 | | - Changing the umask is not thread-safe, so the ACL methods are recommended |
84 | | - when they are available. |
85 | | - |
86 | | -.. _`enable ACL support`: https://help.ubuntu.com/community/FilePermissionsACLs |
| 16 | + If you decide to store log files on disk, you *will* need to make sure your |
| 17 | + logs directory (e.g. ``var/log/``) is writable by your web server user and |
| 18 | + terminal user. One way this can be done is by using ``chmod 777 -R var/log/``. |
| 19 | + Just be aware that your logs are readable by any user on your production system. |
0 commit comments