Contrib.social

Switch drupalci/php-8.3-ubuntu-apache container to use www-data user instead of root

Open on Drupal.org →
Created on 20 November 2024, 2 months ago

Problem/Motivation

Now the drupalci containers are configured with the user "root", so all commands run in the container from the root user with superuser privileges.

But the common approach for containers is to run as non-root user, with the ability to run specific commands as root using the command "sudo".

With the root user approach, we have problems with running commands as non-privileged users, because when switching to the user we're losing the environment variables, write permissions, etc.

Yes, we can invent workarounds for this and are already doing this (see 🐛 BROWSERTEST_OUTPUT_VERBOSE is not passed to run-tests.sh when running with it Active , 📌 Drop using sudo to execute run-tests.sh Active , 🐛 Environment variables are not available in the Nightwatch context Active ), but I think the proper approach to not use the root user by default will be much better.

But, this will be a breaking change, that will require changing not only the "gitlab_templates" pipelines, but also all overridden commands and "before_script" and "after_script" commands, configured in all external projects. The required changes are trivial but still need to be done.

So, to not break the workflow, I'd suggest introducing switching to the new user in a new major version 2.0 of the "gitlab_templates" to let people continue use the previous version without breaking changes.

From the CI file perspective, it can look like this:

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF_V2
    file:
      - '/includes/include.drupalci.main.yml'
      - '/includes/include.drupalci.variables.yml'
      - '/includes/include.drupalci.workflows.yml'

So, what do you think about this idea?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Component

gitlab-ci

Created by

🇦🇲Armenia murz Yerevan, Armenia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @murz
  • Comment 2 months ago →
    🇦🇲Armenia murz Yerevan, Armenia
  • Comment 2 months ago →
    🇪🇸Spain fjgarlin

    Right now, we only have one development branch and we are not thinking about creating a new one or maintaining two versions of the templates (https://project.pages.drupalcode.org/gitlab_templates/help/contributing/). There are many improvements or things that we would have done differently if we were to start again, but I think the templates are stable enough for all contrib.

    With the related issue, if it goes through, we'll have the ability to run tests as root or not, and that would solve problems like the environment variables.

    I'm going to mark this as postponed as it'll either be a breaking change or might require maintaining multiple branches/versions, which we don't want at the moment.

  • Comment 2 months ago →
    🇺🇸United States cmlara

    I believe switching the container itself would actually be a drupalci_environments changes not a gitlab-templates change wouldn't it? in quick reading some runner configs can control the run-user so might even be a drupal-infra issue.

    However before this goes over to another project I want to ask, what is your goal in doing so? Is it you want to provide your own alternative to the drupalci images and your images do not run as root? if so that is actually something we could do today, by adding sudo to EVERY command. The before_script and after_script impacts are on the individual contrib project at that point and are back within not being an api break.

    If this is solely just because of the issues with sudo -H -E for run-tests.sh that issue will be solved. Switching the images to run as www-data just to fix run-tests.sh is as much a workaround as is using the --php flag or trying to run the tests as root. It was been known for a year that it wasn't a sudo issue it was a run-tests.sh bug, no sure why effort was expended in avoiding the root cause.

    Not using root by default isn't really obviously better or worse in the context of these disposable containers, if the running user can gain root seurity risks exist,. In some ways it is actually safer to use root for the 'safe' commands (templates controls and doesn't allow loading 3rd party libraries) and prohibit www-data from having sudo to root (an exploit in a 3rd party library downloaded by composer would not be able to sudo out of the www-data barrier acting as a hindrance to a container escape exploit).

  • Comment about 2 months ago →
    🇪🇸Spain fjgarlin
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024