Opened 3 years ago

Closed 2 years ago

#28909 closed enhancement (fixed)

Allow overriding "when building, check that user isn't root" for use in Docker containers with configure --enable-build-as-root

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-9.1
Component: build: configure Keywords:
Cc: fbissey, jhpalmieri, dimpase, vbraun, jdemeyer, saraedum Merged in:
Authors: Matthias Koeppe Reviewers: Volker Braun
Report Upstream: N/A Work issues:
Branch: 6b5f27a (Commits, GitHub, GitLab) Commit: 6b5f27ad21b7e68ce440a80f36bc1abb3e5f7ae3
Dependencies: Stopgaps:

Status badges

Description (last modified by mkoeppe)

#17420 added AX_CHECK_ROOT, which refuses to configure a sage build as root, as a safety measure protecting users from getting themselves into trouble with sudo make.

On containers, however, building as root is quite natural. We provide an option --enable-build-as-root. (Then we fix all related build system bugs that stop this from working) This would allow us to simplify docker/Dockerfile, which currently works around it:

# Sage refuses to build as root, so we add a "sage" user that can sudo without a password.
# We also want this user at runtime as some commands in sage know about the user that was used during build.
ARG HOME=/home/sage
RUN adduser --quiet --shell /bin/bash --gecos "Sage user,101,," --disabled-password --home "$HOME" sage \
    && echo "sage ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers.d/01-sage \
    && chmod 0440 /etc/sudoers.d/01-sage
# Run everything from now on as the sage user in sage's home
USER sage
ENV HOME $HOME

For example, GitHub Actions do not like Docker containers that make use of the USER command: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners#docker-container-filesystem

Reported build failures as root user:

Change History (13)

comment:1 Changed 3 years ago by mkoeppe

  • Branch set to u/mkoeppe/allow_overriding__when_building__check_that_user_isn_t_root__for_use_in_docker_containers

comment:2 Changed 3 years ago by mkoeppe

  • Cc saraedum added
  • Commit set to 6b5f27ad21b7e68ce440a80f36bc1abb3e5f7ae3
  • Description modified (diff)
  • Status changed from new to needs_review
  • Summary changed from Allow overriding "when building, check that user isn't root" for use in Docker containers to Allow overriding "when building, check that user isn't root" for use in Docker containers with configure --enable-build-as-root

New commits:

6b5f27aAdd configure option --enable-build-as-root

comment:3 Changed 3 years ago by mkoeppe

  • Authors set to Matthias Koeppe

comment:4 Changed 3 years ago by saraedum

Is there some other way we can work around the GitHub Actions problem? Afaik it's considered bad (though common) practice to run processes inside containers as root.

comment:5 Changed 3 years ago by vbraun

Bad but common practice nicely sums up the current state of affairs...

comment:6 Changed 3 years ago by mkoeppe

  • Milestone changed from sage-9.0 to sage-wishlist

comment:7 Changed 3 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

comment:8 follow-up: Changed 3 years ago by saraedum

Thanks for adding this configuration option. It makes sense to be able to override this. However, I don't think we should change our docker images to run as root. It might be helpful for some people but at the same time it creates a problem for other use cases.

What's the situation with GitHub Actions exactly? They ignore USER or they do not allow it at all? If they just ignore it, can we su to sage in our entrypoint if we happen to be root?

So, problem seems to be that GITHUB_WORKSPACE is owned by root. If you are not root you do not get access to that. I don't know enough about GitHub Actions but it seems that their interface is very limited, so you don't get to change the USER. (And you also don't get to run an initialization container that could chmod the workspace.)

Last edited 3 years ago by saraedum (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by mkoeppe

Replying to saraedum:

Thanks for adding this configuration option. It makes sense to be able to override this. However, I don't think we should change our docker images to run as root. It might be helpful for some people but at the same time it creates a problem for other use cases.

I think in this discussion, one should distinguish building sage from running sage:

  • I think building sage as root in the container is unproblematic.
  • A docker image intended to provide a ready to use jupyter server clearly has no business of running that sever as root; in fact, perhaps it should actually be running as a less privileged user than the one that owns the sage installation...
  • There is value in having a Docker image in which sagemath is installed as root in /usr/local and no special preparations such as users or entrypoints are made. This image would then be easy to use in GitHub actions or similar contexts. (Right now I am using conda to set up such a Docker image for my purposes - but it would be nice to have an official Docker image of sagemath that is built from source.)

comment:10 in reply to: ↑ 9 Changed 3 years ago by saraedum

Replying to mkoeppe:

Replying to saraedum: I think in this discussion, one should distinguish building sage from running sage:

True.

  • I think building sage as root in the container is unproblematic.

Yes, but it probably does not win you much.

  • A docker image intended to provide a ready to use jupyter server clearly has no business of running that sever as root; in fact, perhaps it should actually be running as a less privileged user than the one that owns the sage installation...

Some people want to be able to pip install things for example. For this it makes sense to own the Sage installation. (without being root.)

  • There is value in having a Docker image in which sagemath is installed as root in /usr/local and no special preparations such as users or entrypoints are made. This image would then be easy to use in GitHub actions or similar contexts. (Right now I am using conda to set up such a Docker image for my purposes - but it would be nice to have an official Docker image of sagemath that is built from source.)

I agree but having a separate image comes at a significant maintenance cost.

comment:11 follow-up: Changed 2 years ago by chapoton

What is the intended meaning of positive review for a sage-wishlist ticket ?

comment:12 in reply to: ↑ 11 Changed 2 years ago by mkoeppe

  • Milestone changed from sage-wishlist to sage-9.1

Replying to chapoton:

What is the intended meaning of positive review for a sage-wishlist ticket ?

I think it means "wish granted".

comment:13 Changed 2 years ago by vbraun

  • Branch changed from u/mkoeppe/allow_overriding__when_building__check_that_user_isn_t_root__for_use_in_docker_containers to 6b5f27ad21b7e68ce440a80f36bc1abb3e5f7ae3
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.