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

[armetiz]

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

[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.

[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

[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.

[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.

[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.

[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

[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

[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.

[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

[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?

[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.

[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]

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 🤷🏻‍♂️

[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]

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

[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.

[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 :)