Symfony4 recipe - writable setfacl "Operation not permitted" at second deployment

[romainguerrero]

• Deployer version: 6.8.0
• Deployment OS: Debian GNU/Linux 11 (bullseye)

I have the same problem as reported on closed issues #1976 and #2044 but where the problems seems to not have been understood. Maybe this issue will resolve the problem 🤞

I use the Symfony4 recipe to deploy my application and this recipe indicates that the default shared dirs are 'var/log', 'var/sessions' and the writable dir 'var'.

Here is my very simple deploy.php :

<?php

namespace Deployer;

require 'recipe/symfony4.php';

// Configuration
set('repository', 'git@XXX.git');

add('shared_dirs', ['public/uploads', 'public/media', 'public/pdf']);
add('writable_dirs', ['public/uploads', 'public/media', 'public/pdf']);

// Servers
host('preprod')
    ->hostname('XXX')
    ->user('deploy')
    ->set('branch', 'develop')
    ->set('deploy_path', '/var/www/XXX')
;

If the first deployment was a success, I tried to deploy a new version of my code a few days later and I have now this issue :

  [Deployer\Exception\RuntimeException (1)]                                                                                                  
  The command "cd /var/www/XXX/releases/2 && (setfacl -L -R -m u:"www-data":rwX -m u:`whoami`:rwX var)" failed.  
                                                                                                                                             
  Exit Code: 1 (General error)                                                                                                               
                                                                                                                                             
  Host Name: preprod                                                                                                                         
                                                                                                                                             
  ================                                                                                                                           
  setfacl: var/log/prod-2022-01-28.log: Operation not permitted
  ...

After some investigations, the problem is that the writable code for ACL checks first if the writable folder has ACL configuration for the web server user (here www-data). See recipe/deploy/writable.php#L115 :

// Check if ACL has been set or not
$hasfacl = run("getfacl -p $dir | grep \"^user:$httpUser:.*w\" | wc -l");
// Set ACL for directory if it has not been set before
if (!$hasfacl) {
    run("setfacl -L $recursive $setFaclUsers $dir");
    run("setfacl -dL $recursive $setFaclUsers $dir");
}

Here the global directory 'var' is a fresh one from the git clone, so it hasn't ACL configuration, so the if statement make the code try to set ACL on it, but as the symlinked subfolders log or session contain files created by the webserver, the command fails.
As indicated by this documentation :

Requirement: To issue setfacl, you must be the file owner or have superuser authority
And as the deploy user is neither the owner (here www-data) neither a sudo, the setfacl command fails.

To avoid this issue, the solution is to update the recipe to specify the subfolders (like it was done is Symfony 3 recipe) :

- set('writable_dirs', ['var']);
+ set('writable_dirs', ['var/cache', 'var/log', 'var/sessions']);

With this configuration, at the second deployment, the writable code is now able to check get the information that the 'var/log' and 'var/sessions' folders have already ACL configuration for the web server user, and avoid to call the setfacl function. It will only be called by default on the fresh new empty var/cache folder.

[romainguerrero]

Temporary fix is to override the writable_dirs variable on the local deploy.php :

set('writable_dirs', ['var/cache', 'var/log', 'var/sessions']);

[antonmedv]

Try to add your deploy user to www-data group.

[romainguerrero]

This is already done, but as mentioned in my issue the problem is that to issue setfacl you must be the file owner. Be part of the group of the owner doesn't allow you to use setfacl on it.

[antonmedv]

But default ACL on var dir also set to rwX. The prod-2022-01-28.log file should inherit those, isn't it?

[romainguerrero]

Yes, the file has correct permissions, but as the ACL doesn't change the owner, the log file is still owned by www-data.
Here is the process : at the first deployment, deployer creates all needed folders like var and inside cache, log and sessions (knowing that the 2 lasts are symlinked in the share folder). Deployer checks if there is an ACL configuration for www-data for the writable dir (here var) and as it's not the case, it set acl to this folder and all files and subfolders.

After this first deployment, apache creates this prod-2022-01-28.log file (acl are OK, but the owner is www-data which is logical).

Now if we run another deployment :

1. With the current code : deployer checks if there is an ACL configuration for www-data for the writable dir var and because it's a new release folder, it's not the case so it tries to set acl to this folder and all files and subfolders but fails on the log file because the deploy user is not the owner
2. With my PR : deployer checks ACL only for the subfolders like var/log and var/sessions and as they already have configuration for www-data, it doesn't try to set ACL again

[antonmedv]

Now I get it. Thanks for explanation.

What if you disable recursive mode?

[romainguerrero]

Yes it will "work" meaning there will be not error at deployment, but the result will not be the one expected : if I disable recursive mode, the only folder to have ACL configuration will be var, so var/cache, var/log and var/sessions will not be affected and the web server user (www-data in my example) will not be able to have right access.
Another solution may be to remove the recursive mode from the setfacl command, and to the recursivity manually in PHP : for each writable_dir, the code will get each folder to get ACL and if need set them on it, then do the same for this folder subfolders, and so on... But I don't know if this could resolve the problem as some folders (like for sessions saving) could be created by the web server user, so the issue will be the same...

[antonmedv]

Yes, makes sense. Let me measure how slow it will be to do a manual dir traversal.

[romainguerrero]

Ok thank you.
If the manual dir traversal could be an option, a solution to avoid the problem I mention could be to check before doing the setfacl if the current user is the owner of the folder in order to avoid to try setting ACL and get an error if not. But it can slow again the process