NeedsSudoCheck docker detection not working with Docker Buildx

[vtsykun]

This error related with #11839 but now for Docker builds. As I see composer has docker detections to allow run plugins under root only if it running into docker

        $needsSudoCheck = !Platform::isWindows()
            && function_exists('exec')
            && !Platform::getEnv('COMPOSER_ALLOW_SUPERUSER')
            && (ini_get('open_basedir') || !file_exists('/.dockerenv'));

But after updating the composer the docker builds that were launched under GitHub Action began to fail. But local docker build . works fine.

#12 [ 6/10] RUN composer install --no-interaction --no-suggest --no-dev --no-scripts &&     \
   chown www-data:www-data -R /var/www &&     rm -rf /root/.composer &&    \
   rm -rf vendor/oro/doctrine-extensions/tests vendor/cebe/markdown/tests vendor/monolog/monolog/logo.jpg

#12 1.334   - Installing symfony/flex (v2.4.4): Extracting archive
#12 1.346 The "symfony/flex" plugin was not loaded as plugins are disabled.
#12 1.348   - Installing symfony/runtime (v6.4.3): Extracting archive
#12 1.354 The "symfony/runtime" plugin was not loaded as plugins are disabled.
#12 1.355   - Installing psr/container (2.0.2): Extracting archive

#14 [ 8/10] RUN export COMPOSER_ALLOW_SUPERUSER=1;     composer run-script auto-scripts;     mkdir var/composer var/zipball;     rm -rf /root/.composer var/cache
#14 0.172 Executing script cache:clear [KO]
#14 0.191  [KO]
#14 0.191 Script cache:clear returned with error code 255
#14 0.191 !!  
#14 0.191 !!  Fatal error: Uncaught LogicException: Symfony Runtime is missing. Try running "composer require symfony/runtime". in /var/www/packagist/bin/console:8
#14 0.191 !!  Stack trace:
#14 0.191 !!  #0 {main}
#14 0.191 !!    thrown in /var/www/packagist/bin/console on line 8
#14 0.191 !!  
#14 0.198 mkdir: can't create directory 'var/composer': No such file or directory
#14 0.198 mkdir: can't create directory 'var/zipball': No such file or directory

You may use this github action to reproduce bug.

jobs:
    build-and-publish:
        runs-on: ubuntu-latest
        
        steps:
            -   name: Set up Docker Buildx
                uses: docker/setup-buildx-action@v3

            -   name: Push Docker image to GitHub Container Registry
                uses: docker/build-push-action@v5
                with:
                    context: .
                    file: Dockerfile
                    push: true
                    tags: ghcr.io/${{ github.repository }}:latest
                    platforms: linux/amd64
                    cache-from: type=gha,scope=${{ github.workflow }}
                    cache-to: type=gha,scope=${{ github.workflow }},mode=max

[goldmont]

Same problem here, using GitLab.

[ES-Six]

It seem's plugins are not loaded, this seems related to this issue : #11839

Composer release 2.7.0 changelog stated this :

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 https://github.com/composer/composer/issues/11839

Solution mentioned in the issue above is :

• adding an environment variable COMPOSER_ALLOW_SUPERUSER=1 before running composer commands.
• Or, avoid to run composer as root

[vtsykun]

• Or, avoid to run composer as root

I think that using root when building in docker is a normal use case and composer must allow it

[stof]

@vtsykun and composer supports allowing it. That's what the environment variable is about.

[vtsykun]

and composer supports allowing it. That's what the environment variable is about.

Seems the file '/.dockerenv' doesn't exists on docker buildx https://github.com/vtsykun/packeton/actions/runs/7891077144/job/21534639787#step:4:491

#14 [ 8/11] RUN ls -la / &&     printenv
#14 0.066 total 72
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 13 18:27 .
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 13 18:27 ..
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:37 bin
#14 0.066 drwxr-xr-x    5 root     root           360 Feb 13 18:27 dev
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 13 18:27 etc
#14 0.066 drwxr-xr-x    1 root     root          4096 Jan 27 04:23 home
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:37 lib
#14 0.066 drwxr-xr-x    5 root     root          4096 Jan 26 17:53 media
#14 0.066 drwxr-xr-x    2 root     root          4096 Jan 26 17:53 mnt
#14 0.066 drwxr-xr-x    2 root     root          4096 Jan 26 17:53 opt
#14 0.066 dr-xr-xr-x  220 root     root             0 Feb 13 18:27 proc
#14 0.066 drwx------    1 root     root          4096 Feb 13 18:27 root
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:35 run
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:35 sbin
#14 0.066 drwxr-xr-x    2 root     root          4096 Jan 26 17:53 srv
#14 0.066 dr-xr-xr-x   12 root     root             0 Feb 13 18:26 sys
#14 0.066 drwxrwxrwt    1 root     root          4096 Feb 13 18:26 tmp
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:37 usr
#14 0.066 drwxr-xr-x    1 root     root          4096 Feb 12 18:35 var
#14 0.067 OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=grpc
#14 0.067 PHP_INI_DIR=/usr/local/etc/php
#14 0.067 SHLVL=1
#14 0.067 HOME=/root
#14 0.067 PHP_LDFLAGS=-Wl,-O1 -pie
#14 0.067 PHP_CFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
#14 0.067 PHP_VERSION=8.3.2
#14 0.067 OTEL_TRACE_PARENT=00-5ece33b66a1da3d5dbcf1e06da99f9dc-90547af00d1cce81-01
#14 0.067 GPG_KEYS=1198C0117593[497](https://github.com/vtsykun/packeton/actions/runs/7891077144/job/21534639787#step:4:502)A5EC5C199286AF1F9897469DC C28D937575603EB4ABB725861C0779DC5C0A9DE4 AFD8691FDAEDF03BDF6E460563F15A9B715376CA
#14 0.067 PHP_CPPFLAGS=-fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
#14 0.067 PHP_ASC_URL=https://www.php.net/distributions/php-8.3.2.tar.xz.asc
#14 0.067 PHP_URL=https://www.php.net/distributions/php-8.3.2.tar.xz
#14 0.067 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
#14 0.067 OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=unix:///dev/otel-grpc.sock
#14 0.067 TRACEPARENT=00-5ece33b66a1da3d5dbcf1e06da99f9dc-90547af00d1cce81-01
#14 0.067 PHPIZE_DEPS=autoconf 		dpkg-dev dpkg 		file 		g++ 		gcc 		libc-dev 		make 		pkgconf 		re2c
#14 0.067 ***
#14 0.067 PHP_SHA256=4ffa3e44afc9c590e28dc0d2d31fc61f0139f8b335f11880a121b9f9b9f0634e
#14 0.067 OTEL_TRACES_EXPORTER=otlp
#14 DONE 0.1s

[vtsykun]

Seems the .dockerenv files created only under the old deprecated LXC execution driver. docker/buildx#1447, so relying on its presence to check that process is in a container is not entirely correct

[stof]

As long as docker buildx does not provide a way to detect its usage, composer won't be able to automatically detect it to relax the check about running as root. Once such a detection becomes supported by buildkit, I'm quite sure Composer will accept a PR to use it.

You can still use the COMPOSER_ALLOW_SUPERUSER env variable in the meantime as this works.

[vtsykun]

Yes, I see. Perhaps an alternative solution could be to check root user linux kernel capabilities CAP_NET_RAW CAP_SYS_ADMIN
but I don't know how it do from PHP without FFI.

[stof]

I don't think we can do that.

[Seldaek]

Yeah this is ultimately a docker build issue. If they don't provide us with a way to detect it we're left with random hacks which may or may not break. So please report it there, the more people complain the more likely they'll take this seriously.

[Seldaek]

For github and gitlab actions more specifically we might be able to detect those as they have env vars like GITHUB_ACTIONS present but I'm not sure if the env is available within the containers. If someone can check that'd help.

[goldmont]

For github and gitlab actions more specifically we might be able to detect those as they have env vars like GITHUB_ACTIONS present but I'm not sure if the env is available within the containers. If someone can check that'd help.

Hi,

In GitLab, you have to declare a new CI/CD variable (e.g. called COMPOSER_ALLOW_SUPERUSER). Then in your .gitlab-ci.yml, you have to pass COMPOSER_ALLOW_SUPERUSER as build argument using the --build-arg option like below:
docker build --build-arg COMPOSER_ALLOW_SUPERUSER=$COMPOSER_ALLOW_SUPERUSER ...

Then in your Dockerfile you should do something like this:

FROM ...

ARG COMPOSER_ALLOW_SUPERUSER
ENV COMPOSER_ALLOW_SUPERUSER=$COMPOSER_ALLOW_SUPERUSER

RUN composer install

This should work too:

FROM ...

ARG COMPOSER_ALLOW_SUPERUSER

RUN COMPOSER_ALLOW_SUPERUSER=$COMPOSER_ALLOW_SUPERUSER composer install

Even something like this works well to me:

FROM ...

USER www-data

RUN composer install

USER root