-
Notifications
You must be signed in to change notification settings - Fork 132
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
Entrypoint tries to chown data subdirectories with its non-root user, but that's not useful. #76
Comments
he @juliohm1978 I personal see the need for this and the pain you might have. But Graylog needs to be able to write to some specific directories. I could think of having a function like the following to check that for specific directorys and give a meaningful error message back.
Not sure if that will help if the process in the container - that runs for a reason as user and not root - can't write to the mounted volumen. I'm not that deep into kubernetes or openEBS but how does other handle this situation? How did you work with Elasticsearch? |
The error messages would be an improvement, but they don't really resolve the issue. The real problem, for the use case I mention, is that some container volume solutions are not as easily accessible so that you can just The elasticsearch image uses a different approach. It creates its user during It uses |
I think that's the wrong way to go. In the cubernet environment this is exactly what is required, that a container must not run with root rights. I will try to extend the tests to a Kubernet cluster and revise the compose accordingly. |
I fully understand the security concerns for not using root inside the container, but I'm still trying to reconcile this with the implications on how volume provisioning works today. Fundamentally, the container with its limited user permissions expects its volumes to be fully provisioned. The provisioner -- either manual or dynamic -- should embrace the responsibility of providing proper storage and the permissions so the container is able to read/write as expected. For manual volume provisioning, such as local host directories, that means an administrator issuing For dynamic provisioning, the solution adopted should be able to change these permissions dynamically before deliverying a volume. Either way, information about the permission that needs to be given needs to be available to the provisioner. In practice, it needs to know which Kubernetes allows a pod to run Init Containers before the application container starts, which can bootstrap the environment. The Graylog chart uses The concern raised in the chart PR seems like a valid one to me at this point. If the init container needs to So, right now, I'm not sure which is a better solution. Both PRs can be considered. With the options available now, I'm slightly biased towards your opinion. Should we sacrifice some container security or just add a line of code to the volume provisioning solution? I'm not sure. |
Recent PR from Graylog chart community works around the issue by hard coding the uid:gid in their init container. If this sparks any interest in the future, feel free to reopen or request further discussion. Thank you for the support! |
I'm getting these errors today:
The respective configuration (I'm using Docker Compose v3 file format):
This is my way of setting my logged in user as the user for my containers. In this case, the container should have permission to write to the bind mount that I provide. But it's trying to |
Hi, @rcdailey.
If the volume directory does not exist before the container runs, Docker creates it as |
Graylog fails to start if mounted volumes into
${GRAYLOG_HOME}/data
are not owned by the same user inside the container (uid:1100 gid:1100).This refers to the docker-entrypoint.sh script (line 51).
The entrypoint will list entries in
${GRAYLOG_HOME}/data
and try tochown
them to thegraylog:graylog
user. This only works if the directories are already owned by that user.On that note, the graylog container might as well not even try to
chown
directories if it's running as non-root.A common way to workaround this is to adjust volume permissions from the host where the volume is located and restart the container. That is simple enough if you are running
docker-compose
, NFS volumes, or just testing on your local machine.However, in some cases, volume contents are not accessible from outside the container. As an example, volumes provisioned automatically by OpenEBS in a Kubernetes cluster hide their data in block files replicated throughout the cluster. Changing these permissions is not just a matter of chowning a directory in the host OS, and further hacks need to be improvised (such as this one, where I'm trying to workaround by adjusting the helm chart for a Kubernetes deployment).
I'm still trying to think of ways to improve this. I'm not sure what the best approach would be.
Maybe, run the Graylog container as root and, at the end of the entrypoint, launch the graylog process with another user?
The text was updated successfully, but these errors were encountered: