DDEV v1.17.5 composer 2.1.* doesn't set executable bit of phar files (deployer/dist package)

[blankse]

Describe the bug
I use ddev with WSL.
When I use following composer.json and execute an composer without ddev composer install:

{
    "require": {
        "deployer/dist": "^6.8"
    }
}

I can use the PHAR binary with: vendor/bin/dep

When I use it with ddev:

ddev composer install
ddev exec vendor/bin/dep

I get following error:

vendor/bin/dep: 14: vendor/bin/dep: /var/www/html/vendor/deployer/dist/dep: Permission denied
Failed to execute command vendor/bin/dep: exit status 126

[rfay]

@blankse I just tried this with your composer.json and didn't have any trouble.

Could you please execute this command in your project directory in wsl2 and show the results?

pwd && id -a && ls -lL vendor/bin/dep

My only suspicion is that you don't have your project on a native WSL2 partition (like /home), which is absolutely necessary for performance reasons.

Here's what I see:

$ pwd && id -a && ls -lL vendor/bin/dep
/home/rfay/workspace/junk
uid=1000(rfay) gid=1000(rfay) groups=1000(rfay),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(lxd),114(netdev),1001(docker)
-rwxr-xr-x 1 rfay rfay 1062898 Apr 25  2020 vendor/bin/dep

And...

$ ddev exec vendor/bin/dep
Deployer 6.8.0

Usage:
  command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -f, --file[=FILE]     Specify Deployer file
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Available commands:
  autocomplete  Install command line autocompletion capabilities
  help          Displays help for a command
  init          Initialize deployer in your project
  list          Lists commands
  run           Run any arbitrary command on hosts
  self-update   Updates deployer.phar to the latest version
  ssh           Connect to host through ssh
 debug
  debug:task    Display the task-tree for a given task

[blankse]

@rfay I am in /home and in WSL the file permission of the vendor/bin/dep proxy file is correct.

datafactory@tyrael:~/wwwroot/composer-test$ pwd && id -a && ls -lL vendor/bin/dep
/home/datafactory/wwwroot/composer-test
uid=1000(datafactory) gid=1000(datafactory) groups=1000(datafactory),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),117(netdev),1001(docker)
-rwxr-xr-x 1 datafactory datafactory 348 Jun  9 14:12 vendor/bin/dep

The permission from the target vendor/deployer/dist/dep is wrong:

datafactory@composer-test-web:/var/www/html$ ls -lL vendor/deployer/dist/dep
-rw-r--r-- 1 datafactory datafactory 1062898 Apr 25  2020 vendor/deployer/dist/dep

Edit: Did you test with the current composer version? I think only composer 2.1.x is affected.

[blankse]

@rfay Okay is not a fault of ddev. Doesn't work without DDEV either. My local composer was 2.0.x

[rfay]

No, ddev on my WSL2 was a little older and had composer 2.0.12.

After upgrading I confirm the same results that you have.

Note that you can set composer_version: 2.0.14 in .ddev/config.yaml to roll back to 2.0.x

Please open an issue with composer or deployer/dist and put the link here. (It doesn't look like this is fixed in 2.1.2 either)

[rfay]

I note that this doesn't seem to be a general problem. ddev composer require drush/drush seems to do just fine, with the permissions of vendor/bin/drush and vendor/drush/drush/drush both set correctly.

[blankse]

@rfay It only affected PHAR files. Are drush a PHAR file?

[blankse]

@rfay I open an issue here: composer/composer#9961

[rfay]

I just found that :) Looks like you already knew all about this.

Note that there shouldn't be any difference in behavior between WSL and general Linux. Composer doesn't know anything about WSL.

[blankse]

@rfay Composer 2.1 detects WSL by looking for "Microsoft" in /proc/version and make the same as on windows...
See composer/composer#9855

[rfay]

Note that ddev composer is running composer in a Debian 10 container though. In that case I don't think composer could have any idea about WSL2.

I do find that the permissions come out correct on a native Ubuntu 20.04 machine and your composer.json using native composer 2.1.2 (not ddev)

[blankse]

@rfay In the web container the /proc/version file contains also microsoft. So composer also use the WSL behavior.

datafactory@composer-test-web:/var/www/html$ cat /proc/version
Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020

Yes in a native Ubuntu Composer use the symlink behavior instead of the proxy file. So the permission is set correct to the target file.

[rfay]

And now I see https://github.com/composer/composer/releases/tag/2.1.3 with a fix for this I guess.