Rationale for dac_override capability

[lkubb]

First of all, thank you for your work on searx/searxng, I appreciate it very much.

I hope this is the correct repository to file the issue since it is visible here, but it might be related to the main repo.

According to this RedHat blog article, no container should require CAP_DAC_OVERRIDE. It was introduced in https://github.com/searxng/searxng-docker/commit/4023196f5494b8a0934ceff68771ad86e33edbd9 as a bugfix, but the commit does not specify the underlying issue. Is there still a cause for the containers needing this capability?

I skimmed the docker entrypoint script (I'm no expert by any means). Is it related to the file operations running as root, e.g. in https://github.com/searxng/searxng/blob/4ef62637256d4b2966ff7f0be0051e02d545f756/dockerfiles/docker-entrypoint.sh#L74-L86? Using su-exec searxng:searxng to run sed/cp/mv could be a simple fix in that case.

[mrpaulblack]

@dalf do you know why its used. I am not sure tbh...

[dalf]

I don't remember why it was needed.

I've tried quickly to remove CAP_DAC_OVERRIDE:

• Caddy: seems ok even with a empty new docker volumes.
• SearXNG: seems ok after a quick test, but it requires more attention.

---

Out of topic : it would be better to just mount /etc/searxng/settings.yml (which could use use_default_settings: True or not). The docker image could start without the root user.

[magnus919]

Bumping this for visibility as I came to ask the same question.

If DAC_OVERRIDE provides no known benefit, and if the service passes tests without it, can it not be safely removed?

[magnus919]

I don't remember why it was needed.

I've tried quickly to remove CAP_DAC_OVERRIDE:

• Caddy: seems ok even with a empty new docker volumes.
• SearXNG: seems ok after a quick test, but it requires more attention.

Out of topic : it would be better to just mount /etc/searxng/settings.yml (which could use use_default_settings: True or not). The docker image could start without the root user.

It doesn't seem very dockery to mount a config file from outside of the container. Should be able to take all of the config it needs at runtime from the inherited environment, no?