Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the container to run as non-root, with a readonlyrootFS #682

Open
davralin opened this issue Nov 18, 2024 · 4 comments
Open

Allow the container to run as non-root, with a readonlyrootFS #682

davralin opened this issue Nov 18, 2024 · 4 comments

Comments

@davralin
Copy link

Description

As mentioned from my comment in #663 , the container runs with very high privileges, which stops it from running in environments where higher levels of security is needed/wanted.

Most of the things can be fixed, with some refactoring of both dockerfiles and the entrypoint, however:

  • It will be a breaking change, as it would have to change the listening port in apache to be something above 1024.
  • That will also break the intended (?) purpose of the container being available on default tcp/80 with network_mode: host (network_mode: host will still work, but the container will listen to (for instance) tcp/8080 instead)
  • Something needs to chown the datadir with the sqlite-database, and it can't be the container, because that operation will require root-privileges

You mention Given this configuration, no further adjustments are needed to meet our security goals. - does this mean you don't want to reconfigure the containers so that they run as non-root, with a readonlyrootFS?
I'd hate to work on a PR, just for it to be declined.

Why it should be implemented

People who don't want root-containers, with full read/write-access to it's own container's file system.

@sstidl
Copy link
Collaborator

sstidl commented Nov 20, 2024

You can go ahead. I understand your intentions better now. As far as I see it there's no need to run in host mode but maybe that's before my time here in the project.
Please try to be clear what your changes are when coding them.
I will review and comment if something is unclear.

Thank you very much for the effort and input and time!

@scyto
Copy link

scyto commented Nov 21, 2024

It is a common misconception that running root in the container is the same as running root on the host it isn't whether you run as root in the container or some other GID/UID you have the same host capabilities

the port issue can be fixed with the existing envar IMO

@davralin
Copy link
Author

Please try to be clear what your changes are when coding them. I will review and comment if something is unclear.

My contributions will most likely only be around the Dockerfile's and the entrypoint, and related documentation for that.
I'm no coder :-)

At a high-level, my plan is to remove most of the things from entrypoint, and move it to a multi-part Dockerbuild.
I think I'm going to deprecate the webport entirely, port-mappings should be sufficient, so it makes no sense to have to configure something twice, in my opinion.
I'm not sure yet, how I can fix all the custom copying in entrypoint.sh in a readonlyrootFS (because that's not possible, after all :-) ) - so that might be something that someone else needs to fix.

@scyto
Copy link

scyto commented Nov 21, 2024

we need the ability to change the port by envar, some of us want to run these on macvlans, or host where port publishing is not required

Wehn you say multipart docker build i want to make sure you are not talking about building the image at run time - just it is multipart for the dcokerfile to produce a static image for the public registry?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants