[BUG] Last build failed

[kevinpapst]

The symfony-cmd was not found

https://github.com/tobybatch/kimai2/actions/runs/3517863216/jobs/5896121624#step:8:3256

[JayJohnsen]

hi guys, I think I have the same error when building the container. Docker build exit with code 127 in stdn.

=> ERROR [linux/amd64 dev 3/3] RUN export COMPOSER_HOME=/composer &&     composer --no-ansi install --working-dir=/opt/kimai --optimize-autoloader &&  52.5s
------
 > [linux/amd64 dev 3/3] RUN export COMPOSER_HOME=/composer &&     composer --no-ansi install --working-dir=/opt/kimai --optimize-autoloader &&     composer --no-ansi clearcache &&     composer --no-ansi require --working-dir=/opt/kimai laminas/laminas-ldap &&     chown -R www-data:www-data /opt/kimai &&     mkdir -p /opt/kimai/var/logs && chmod 777 /opt/kimai/var/logs &&     sed "s/128M/-1/g" /usr/local/etc/php/php.ini-development > /opt/kimai/php-cli.ini &&     sed -i "s/env php/env -S php -c \/opt\/kimai\/php-cli.ini/g" /opt/kimai/bin/console &&     tar -C /opt/kimai -zcvf /var/tmp/public.tgz public &&     /opt/kimai/bin/console kimai:version:
#86 0.552 Composer plugins have been disabled for safety in this non-interactive session. Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user.
#86 0.552 Do not run Composer as root/super user! See https://getcomposer.org/root for details
#86 0.765 Installing dependencies from lock file (including require-dev)
#86 0.807 Verifying lock file contents can be installed on current platform.
#86 0.877 Package operations: 192 installs, 0 updates, 0 removals
#86 0.878   - Downloading composer/package-versions-deprecated (1.11.99.5)
---- snipped ----
#86 50.73 Package symfony/inflector is abandoned, you should avoid using it. Use EnglishInflector from the String component instead.
#86 50.73 Package php-cs-fixer/diff is abandoned, you should avoid using it. No replacement was suggested.
#86 50.73 Generating autoload files
#86 51.13 140 packages you are using are looking for funding.
#86 51.13 Use the `composer fund` command to find out more!
#86 52.25 > symfony-cmd
#86 52.26 sh: symfony-cmd: not found
#86 52.26 Script symfony-cmd handling the auto-scripts event returned with error code 127
#86 52.26 Script @auto-scripts was called via post-update-cmd
------
Dockerfile:258
--------------------
 257 |     # do the composer deps installation
 258 | >>> RUN export COMPOSER_HOME=/composer && \
 259 | >>>     composer --no-ansi install --working-dir=/opt/kimai --optimize-autoloader && \
 260 | >>>     composer --no-ansi clearcache && \
 261 | >>>     composer --no-ansi require --working-dir=/opt/kimai laminas/laminas-ldap && \
 262 | >>>     chown -R www-data:www-data /opt/kimai && \
 263 | >>>     mkdir -p /opt/kimai/var/logs && chmod 777 /opt/kimai/var/logs && \
 264 | >>>     sed "s/128M/-1/g" /usr/local/etc/php/php.ini-development > /opt/kimai/php-cli.ini && \
 265 | >>>     sed -i "s/env php/env -S php -c \/opt\/kimai\/php-cli.ini/g" /opt/kimai/bin/console && \
 266 | >>>     tar -C /opt/kimai -zcvf /var/tmp/public.tgz public && \
 267 | >>>     /opt/kimai/bin/console kimai:version
 268 |     ENV APP_ENV=dev
--------------------
error: failed to solve: rpc error: code = Unknown desc = process "/bin/sh -c export COMPOSER_HOME=/composer &&     composer --no-ansi install --working-dir=/opt/kimai --optimize-autoloader &&     composer --no-ansi clearcache &&     composer --no-ansi require --working-dir=/opt/kimai laminas/laminas-ldap &&     chown -R www-data:www-data /opt/kimai &&     mkdir -p /opt/kimai/var/logs && chmod 777 /opt/kimai/var/logs &&     sed \"s/128M/-1/g\" /usr/local/etc/php/php.ini-development > /opt/kimai/php-cli.ini &&     sed -i \"s/env php/env -S php -c \\/opt\\/kimai\\/php-cli.ini/g\" /opt/kimai/bin/console &&     tar -C /opt/kimai -zcvf /var/tmp/public.tgz public &&     /opt/kimai/bin/console kimai:version" did not complete successfully: exit code: 127

[tobybatch]

The issue is with LDAP symfony plugin. I'll look at getting that fixed.

[tobybatch]

Or maybe not. @kevinpapst I see

https://github.com/kevinpapst/kimai2/blob/master/composer.json#L147

But when I don't seem to have symfony-cmd installed, this was run in the container:

bash-5.1$ find . -name symfony-cmd
bash-5.1$ find ~ -name symfony-cmd
bash-5.1$ find / -name symfony-cmd 2>/dev/null

I see that the instructions for symfony cli seem to have renamed the command to just symfony. Any suggestions?

https://symfony.com/download

Or is that something else?

[kevinpapst]

The composer entries are something else. It doesn't work locally as well if I try to run symfony-cmd. It is a "shortcut" that tells the Symfony-Flex-Plugin (for composer) to execute this command: https://github.com/symfony/flex/blob/1.x/src/ScriptExecutor.php#L83

Not sure what happens, but there are two possible reasons I can think of:

• The flex plugin is not executed, but I do not see the --no-plugins flag in the composer calls (which would deactivate the flex plugin).
• The linked uses this logic $console = ProcessExecutor::escape($this->options->get('root-dir').'/'.$this->options->get('bin-dir').'/console'); - maybe something changed that the path can now not be detected properly.

But my vote goes to the first point, that the flex plugin wasn't executed and then composer tries to simply execute what is written there. So it is trying to spawn a process with symfony-cmd which is not exeisting.

Usually this code in the Kimai composer.json allows the Flex plugin to be executed: https://github.com/kevinpapst/kimai2/blob/master/composer.json#L116

[kevinpapst]

Ah damn, after writing this poem I found the reason and it is right in front of us: https://github.com/tobybatch/kimai2/actions/runs/3517863216/jobs/5896121624#step:8:3233

Composer plugins have been disabled for safety in this non-interactive session. Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user.

Can you please try that @tobybatch ? I am about to push a new patch release, so we can immediately try the change.

[tobybatch]

@kevinpapst I'll take a look tonight :crossed_fingers: the CI should just get it. :smiley:

[tobybatch]

If the patch doesn't work I can drop privs earlier in the build, or allow SU

[JayJohnsen]

Ah damn, after writing this poem I found the reason and it is right in front of us: https://github.com/tobybatch/kimai2/actions/runs/3517863216/jobs/5896121624#step:8:3233

Composer plugins have been disabled for safety in this non-interactive session. Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user.

Can you please try that @tobybatch ? I am about to push a new patch release, so we can immediately try the change.

@kevinpapst you are right. i just ran a test locally and ENV COMPOSER_ALLOW_SUPERUSER=1 fix the error for now. but referring to #86 0.552 Do not run Composer as root/super user! See https://getcomposer.org/root for details the composer docs 'strongly advised to avoid running Composer as super-user/root'.

[kevinpapst]

@tobybatch any chance that you can push the fix with the new env? I'd do it myself, but I don't know where to start... and I get emails why the docker image is not up-to-date 🙈

[kevinpapst]

Well, I have no clue what I am doing, but if you could verify #434 @JayJohnsen that would be awesome!

[JayJohnsen]

@kevinpapst well, i have no clue too. For now i have just added , like you do, ENV COMPOSER_ALLOW_SUPERUSER=1 to the # global base build section of the Dockerfile. I am not familiar with Composer but in the log was a link to https://getcomposer.org/root

How do I install untrusted packages safely? Is it safe to run Composer as superuser or root?# Why am I seeing a "Do not run Composer as root/super user" warning/error?#

It was always discouraged to run Composer as root for the reasons detailed below.

As of Composer 2.4.2, plugins are disabled automatically when running as root and there is no sign that the user is consciously doing this. There are two ways this user consent can be given:

If you run interactively, Composer will prompt if you are sure that you want to continue running as root. If you run non-interactively, plugins will be disabled, unless..
If you set the [COMPOSER_ALLOW_SUPERUSER](https://getcomposer.org/doc/03-cli.md#composer-allow-superuser) environment variable to 1, this also indicates that you intended to run Composer as root and are accepting the risks of doing so.

Is it safe to run Composer as superuser or root?#

Certain Composer commands, including exec, install, and update allow third party code to execute on your system. This is from its "plugins" and "scripts" features. Plugins and scripts have full access to the user account which runs Composer. For this reason, it is strongly advised to avoid running Composer as super-user/root. All commands also dispatch events which can be caught by plugins so unless explicitly disabled installed plugins will be loaded/executed by every Composer command.

You can disable plugins and scripts during package installation or updates with the following syntax so only Composer's code, and no third party code, will execute:

php composer.phar install --no-plugins --no-scripts ... php composer.phar update --no-plugins --no-scripts ...

Depending on the operating system we have seen cases where it is possible to trigger execution of files in the repository using specially crafted composer.json. So in general if you do want to install untrusted dependencies you should sandbox them completely in a container or equivalent.

Also note that the exec command will always run third party code as the user which runs composer.

See the COMPOSER_ALLOW_SUPERUSER environment variable for more info on how to disable the warnings.

But I'm not sure if that's the case here because it's quite common to run processes in the container as root.

[kevinpapst]

Let's not get in the root discussion. Composer has to announce that and it is obviously true for various reasons.

But: we are in a container and the content of the composer file is known and the plugins can be trusted.

The env is a "quick fix". I assume dropping permissions earlier is way more work for @tobybatch and for now I am mostly interested in getting build back to work.

So if you did the same with then ENV call, then this is good feedback. Thanks!

[JayJohnsen]

Sorry @kevinpapst it´s not my goal to start a root discussion! I´m not a native speaker i was not sure what want to onfirmed. sorry i am just at work. i gues i call the Env a bit later in the final builds... but i gues it dosent matter. I can send you my Dockerfile if i have finished my Job. Thanks a lot for your Work!

[kevinpapst]

Nothing to be sorry about, I appreciate any input/feedback! I am using GitHub daily, so I sometimes forget that processes here are not as clear if you are not used to it.

[tobybatch]

@kevinpapst @JayJohnsen

Dropping perms earlier is a way better option. I'll add that to the TODO list. I'll push a fix using the env var tonight. Sorry busy with the day job recently.

@JayJohnsen Like Kevin I'm always open to to constructive suggestions.

[tobybatch]

Just pushed a fix. It build fine locally. I'll re-trigger the git hub action

[kevinpapst]

Re-running the old builds will fail, as the action will checkout the old code again.

I triggered it from Kimai repo again, seems to have worked!