Composer 2.7.0 usage with root user leads to plugins not being loaded

[armetiz]

Edit from @Seldaek: Here is an explanation and solution:

The problem stems from the fact that when running as root, for safety we now disable plugins. If running interactively Composer prompts you whether you want to enable them, but when non-interactive we just disable them and output a warning.

If you want to allow plugins to run you should set the COMPOSER_ALLOW_SUPERUSER=1 environment variable. This will suppress the warning and let Composer run as usual even when running as root.

However, you should IMO only do this if you can ensure you run trusted code, or if you are in a disposable environment/containerized CI that will get reset at the end of the run anyway. If you run composer with sudo in production machines however IMO you are likely doing something wrong and you should re-evaluate these processes instead of simply suppressing the errors.

See also https://getcomposer.org/doc/faqs/how-to-install-untrusted-packages-safely.md

---

---

Original issue text:

Our running platform is AWS ElasticBeanstalk.
The deployment process is failing when using composer 2.7.0 whereas success when using 2.6.6.

sh: symfony-cmd: command not found
Script symfony-cmd handling the auto-scripts event returned with error code 127

The problem is that AWS ElasticBeanstalk run composer as root (as I can see from logs).
composer 2.7.0 is fixing CVE-2024-24821..

To solve the problem, I force the version of composer to version 2.6.6 : composer self-upgrade 2.6.6.

I opened this issue to help other people to find a solution.

[Seldaek]

I don't quite understand how it breaks. Maybe if you shared the full output we'd know more..

Setting COMPOSER_ALLOW_SUPERUSER=1 might fix it, assuming that it breaks because plugins are now disabled correctly when running as root.

But it's just a guess..

And I'm not sure if it's appropriate or not for ElasticBeanstalk to run as root, nor if it is reasonable to allow plugins to run in this context.

Anyway please report this to AWS, as they really should fix it if it breaks by default there.

[oliveradria]

I had the same problem in bitbucket-pipelines.yaml. It's a simple setup, but I managed to fix it for now by adding a self-update

- curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
- composer self-update 2.6.6  # <-- without this, it fails
- composer install --prefer-dist --no-interaction

Online research shows, that this usually fails when symfony/flex is not installed, but I just updated it now to 2.4.4 and made sure it was installed.

Edit:
Error is the same

Generating optimized autoload files

x packages you are using are looking for funding.

Use the `composer fund` command to find out more!

> symfony-cmd

sh: 1: symfony-cmd: not found

Script symfony-cmd handling the auto-scripts event returned with error code 127

Script @auto-scripts was called via post-install-cmd

[stof]

This symfony-cmd thing is indeed something that cannot work if the symfony/flex plugin is not enabled.

[oliveradria]

Sorry, maybe I wrote it wrong.

I meant, usually it is because of the symfony/flex missing, but it was available in my project.

But to be sure, I updated it in my project to the current version 2.4.4, and in the pipeline I checked that it was properly installing and also that it is in the require (not require-dev) section of composer.json.

But I still get the error message. When I add

- composer self-update 2.6.6

to bitbucket-pipelines.yaml config, it works again. The script config is

    script:
        - apt-get update && apt-get install -y unzip
        - docker-php-ext-install pdo_mysql
        - cp .env.ci .env
        - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
        - composer self-update 2.6.6
        - composer install --prefer-dist --no-interaction
        - ./vendor/bin/phpunit --testdox --colors="always"

Nothing fancy, I suppose. Currently on php:8.2

[Seldaek]

It's bitbucket pipelines running everything as root? Do you see a composer warning that plugins have been disabled because it's running as root?

If so try setting the COMPOSER_ALLOW_SUPERUSER=1 environment variable, that's a more appropriate fix than downgrading

[oliveradria]

Ah, brilliant, thank you @Seldaek !

                  script:
                      - apt-get update && apt-get install -y unzip
                      - docker-php-ext-install pdo_mysql
                      - cp .env.ci_test .env
                      - cp .env.ci_test .env.test
                      - export COMPOSER_ALLOW_SUPERUSER=1
                      - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
                      - composer install --prefer-dist --no-interaction
                      - ./vendor/bin/phpunit --testdox --colors="always"

This works without a problem and with composer v2.7.0.

[Seldaek]

Ok, then i wonder what we can do to make the warning about plugins more visible / understandable..

[Seldaek]

The way I see it, the warning is quite clear and visible, but 🤷🏻‍♂️

[oliveradria]

For me it looks like this

and the error

sh: 1: symfony-cmd: not found

shows up after about 190 lines. So maybe I just didn't make the connection that it was the root user thing on lines 2/3 that caused it.

[oliveradria]

Perhaps what had confused me is that I didn't change anything relevant from yesterday, but it just suddenly stopped working because of the implicit bump up in version from 2.6.6 to 2.7.0, but this was not visible anywhere, whilst the behavior changed.

Perhaps something like adding --strict to make sure that it always stops on warnings is useful.

Or perhaps make it default to stop on warnings, and adding an additional --ignore-warnings if you don't care.

[armetiz]

Hi @Seldaek ,

I guess you right, it's just about this: plugins are now disabled correctly when running as root.

[snk-spo]

Can confirm. Using 2.6.6 or COMPOSER_ALLOW_SUPERUSER=1 are both (nasty but working) workarounds for us.

Some bakground: we are using gitlab-ci with Alpine Linux to install TYPO3 10.4.x which brings its own installer plugin (typo3/cms-composer-installers) to move some files around. This totally fails now because the TYPO3 composer plugin is not executed anymore.

I suspect this final security-fix commit before 2.7.0 was released:
64e4eb3

(I suggest changing the issue title to something more generic.)

[Seldaek]

You're right, I edited the title and issue to add a clear explanation of what is going on and how to work around it and when it is ok to work around. IMO in CI this isn't a nasty workaround it's fine, although I don't really understand why these CI require you to run as root.

I am working on some tweaks to hopefully highlight the problem a bit closer to where it causes things to break.

[maxvisser]

As 2.7 breaks some AWS Elastic Beanstalk production environments, maybe add a quick note to the changelogs of composer. As I read the changelogs but still encountered the issue.

Something like:

If you see errors with missing commands (symfony-cmd: command not found) or other failures and you are relying on plugins and running Composer as root (for example when you use AWS ElasticBeanstalk), read #11839

[Seldaek]

Right, added it 👍🏻

[gnumoksha]

IMHO, this is a breaking change introduced in a minor version but semver states: MINOR version when you add functionality in a **backward compatible** manner.

Now all my containerized symfony applications are failing to deploy, and I don't even use AWS ElasticBeanstalk.

[Seldaek]

It's a security fix which tbh could have even been released in a patch release. Set the env var in your containers and move on?

[daniela-zc]

I am using export "COMPOSER_ALLOW_SUPERUSER=1 " and running "composer install" is still not working for me

[Arr-n-D]

I spent the entire morning debugging why at first, the web folder was not created by Drupal project scaffolding from my Docker image.
I then used the COMPOSER_ALLOW_SUPERUSER=1 setting and that fixed that issue.
I then spent the entire afternoon and evening trying to figure out why commands such as ./vendor/bin/drush from my container would fail with this error

Fatal error: Uncaught Error: Class "Drupal" not found in /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php:93

After reverting COMPOSER_ALLOW_SUPERUSER=1 and applying the composer self-update 2.6.6 solution, things restarted working as intended. This indicates to me that there's more to the solution than just setting COMPOSER_ALLOW_SUPERUSER

[fredden]

@Arr-n-D if you're able to create a repeatable test case for the problem you're encountering, please open a new issue with these details.

[stefanak-michal]

It seems like this change should have been update of major version.

[hkirsman]

This is closed but I'll ask here because maybe somebody sees this. Today we also got lucky and took our productions site down. I'm wondering, shouldn't Composer return error code so Docker would not finish the build? I mean if it's not working properly under root, shouldn't it be more vocal?

[stof]

"not working" depends whether your project requires plugins to run to have something working. The core behavior of composer is still working.

[fede-green]

Eheh, i understand what you mean by "core behavior of composer is still working", but still running composer install one would expect to get a working codebase out of it, instead we got only 4 MB of code instead of the usual 200+MB of code we run in production.

The issue was also quite hard to debug, because logs are quite verbose and also not colorful as in the screenshots up there. I think the safer way of doing such updates would be to return an error code, so that one would go and dig deeper in logs instead of getting a "green" deployment that is not working.

Anyhow, glad we found this :)

[Rikaelus]

Not to beat a dead horse, but for anyone still watching this (or finding this), I'm still seeing issues and my profile seems a bit different.

I'm dealing with Docker and both the initial install process and subsequent uses are often performed as root in our E2E testing environment. When I shell into the container as root and non-root, I get the following (w/ -vvv):

Root:

root@e1e2259154e4:/var/www/html# /tmp/composer -vvv
Reading ./composer.json (/var/www/html/composer.json)
Loading auth config from COMPOSER_AUTH
Loading config file ./composer.json (/var/www/html/composer.json)
Checked CA file /etc/pki/tls/certs/ca-bundle.crt does not exist or it is not a file.
Checked directory /etc/pki/tls/certs/ca-bundle.crt does not exist or it is not a directory.
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Failed to initialize global composer: Composer could not find the config file: /root/.composer/composer.json

Reading /var/www/html/vendor/composer/installed.json
Loading plugin ComposerIncludeFiles\Plugin (from funkjedi/composer-include-files)
Running 2.7.7 (2024-06-10 22:11:12) with PHP 8.2.12 on Linux / 5.15.146.1-microsoft-standard-WSL2
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.7.7 2024-06-10 22:11:12

Non-root:

app@e1e2259154e4:/var/www/html$ /tmp/composer -vvv
Reading ./composer.json (/var/www/html/composer.json)
Loading auth config from COMPOSER_AUTH
Loading config file ./composer.json (/var/www/html/composer.json)
Checked CA file /etc/pki/tls/certs/ca-bundle.crt does not exist or it is not a file.
Checked directory /etc/pki/tls/certs/ca-bundle.crt does not exist or it is not a directory.
Checked CA file /etc/ssl/certs/ca-certificates.crt: valid
Failed to initialize global composer: Composer could not find the config file: /home/app/.composer/composer.json

Reading /var/www/html/vendor/composer/installed.json
Loading plugin ComposerIncludeFiles\Plugin (from funkjedi/composer-include-files)
Activate <======
Running 2.7.7 (2024-06-10 22:11:12) with PHP 8.2.12 on Linux / 5.15.146.1-microsoft-standard-WSL2
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.7.7 2024-06-10 22:11:12

I don't get any warning about plugins not running as root. I also see the funkjedi/composer-include-files plugin load but it only activates as non-root. (I have its activate() method print out).

-n/--no-interaction inclusion/exclusion has no effect.
Setting COMPOSER_ALLOW_SUPERUSER=1 via export or inline has no effect.

P.S. Making this even more preposterous. nothing I try will successfully downgrade composer

root@e1e2259154e4:/tmp# php composer-setup.php --version=2.6.6
All settings correct for using Composer
Downloading...

Composer (version 2.6.6) successfully installed to: /tmp/composer.phar
Use it: php composer.phar

root@e1e2259154e4:/tmp# ./composer.phar 
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.7.7 2024-06-10 22:11:12

Update for posterity:
I was seriously running afoul of Laravel's opcache while trying to use the above suggestions. I'm not sure that explains all the oddities I had along the way but, suffice it to say, adding the environment variable to the very initial install process got the right code in the opcache and working as needed.