Deployer: Avoid making "writable" directories world-writable

[k-solnushkin]

| Q | A |
| --- | --- |
| Issue Type | Feature Request |
| Deployer Version | 3.3.0 |
| Local Machine OS | Ubuntu 16.04.1 LTS |
| Remote Machine OS | Ubuntu 16.04.1 LTS |

Description

"Deployer" uses a very intricate mechanism with setfacl to allow the web server to write to writable directories. setfacl is not installed in Ubuntu by default, and its use is actually not warranted in this simple case. Those "writable" directories can be made accessible to the web server using standard Linux ways. My choice here is this:

sudo chgrp -R www-data shared

Nginx runs under user id "www-data" and group id "www-data", so the command above just makes the shared directory group-owned by "www-data", and that is it. No need to mess with ACLs.

Two benefits are that (1) there is no need to install "setfacl", and (2) there is no need to make the writable directories world-writable (mode 777).

The use of setfacl appeared in this commit:

https://github.com/deployphp/deployer/commit/f5b4a0072a71b9d49a594825200b8c1e5cf0c641#diff-1272beae40bb3bcb456e54596a3bd2f0R142

[antonmedv]

mode 777 used only if it fails to use ACL.

[k-solnushkin]

Hi Anton,

There are two parts to this issue, first is chmod 777 vs. chgrp and the other is about setfacl. Here are two arguments, each for its corresponding part.

The discussion is based on the assumption that most real-world deployments of PHP applications need at most two access modes:

1. $user which is used to perform deployments: needs read-write access to site directories at the time of deployment (and actually _needs no write access_ after deployment is done)
2. $http_user under which the web server is running: needs read-only access to most directories and read-write access to only a few directories

There _could be_ some set-ups where there are more types of users who need other types of access, but I fail to imagine such examples.

The argument against chmod 777:

It's rather obvious that setting directories world-writable (mode 777) is an overkill. Who else needs to write to web application directories other than the web server? This is actually a security concern as well.

Using chgrp $http_user directory to make the directory group-owned solves this issue. Even if there is some process in the system that needs to write to web application folders (which is unlikely), it can be added to the group $http_user and get the same permissions as the web server.

Now, the arguments against setfacl:

1. It's not installed by default on certain systems (such as Ubuntu 16 LTS)
2. It requires the system administrator to constantly keep in mind that certain directories have more permissions than the usual UID and GID. Why have that cognitive burden if we can avoid it?
3. Everything that is achieved in the current common.php recipe that uses setfacl can already by achieved by using chgrp

So, in most of the practical deployment set-ups the use of setfacl, albeit very flexible, is just not warranted.

[antonmedv]

I agree, i think we can try to use * chgrp* in next deployer release and get rid of setfacl.

[k-solnushkin]

Thank you, Anton,
It's very nice to hear. I will be happy to test this feature and provide my feedback, or do other help as appropriate.

[antonmedv]

Done in v4.