Incorrect ownership of /opt/couchdb - everything is owned by couchdb

[arturog]

The Docker image sets everything under /opt/couchdb to be owned by the couchdb user, leading to the running couchdb process to have unrestricted access to all binaries and files installed in the container.

Expected Behavior

Only the necessary directories under /opt/couchdb should be set to be owned by couchdb, namely /opt/couchdb/data, etc...

Current Behavior

Everything is owned by couchdb. Couchdb has unrestricted access to all files installed.

Possible Solution

Change the chown commands in the Dockerfile and entrypoint to selectively set the correct ownerships.

Steps to Reproduce (for bugs)

Run the image
execute docker exec -ti <your-container-name> bash and have a look inside /opt/couchdb

[willholley]

The Docker image sets everything under /opt/couchdb to be owned by the couchdb user.

This is by design. Production environments (e.g. using Docker Compose / Kubernetes) will generally add additional restrictions to the container context. For example, running as a non root user (gid 0), readonly container filesystem and external storage mounted to /opt/couchdb/data. What is the scenario you have where you see a risk with the current approach?

unrestricted access to all binaries and files installed in the container

That's not entirely correct - it should only be scoped to /opt/couchdb - but broadly scoped permissions for the application files are standard practice when combined with the measures described above.

[arturog]

Understood, I'll go out to read more about what best practices should be and apply them to my couchdb Dockerfile.

But the above is happening in the ENTRYPOINT of the Dockerfile, on every run the Dockerfile is chowning the potentially mounted host volume files, even config files. If you feel this is the right thing to do please go ahead and close the issue. If I find more info I'll comment further.

[willholley]

@arturog this only happens if the CouchDB container is running as root. If you use the default entrypoint, the container will start as root, configure file permissions etc and step down to the CouchDB user to run CouchDB itself.

When using a container orchestration system such as Kubernetes or Docker Compose you can bypass this step, either by running a non-root user (in which case you just have to make sure that uid can access /opt/couchdb/data) or by using a different entrypoint entirely. The CouchDB Helm Chart is one example of mounting an external volumes to /opt/couchdb/data creating the config files explicitly.

[arturog]

Thanks for the info, I'll review my docker-compose. Also, I'll see if adding USER to the Dockerfile makes sense.

[willholley]

with docker you can set the uid at runtime e.g,
``
mkdir /Users//temp/couchdb-data
docker run --user --name mycouch -v /Users//temp/couchdb-data:/opt/couchdb/data -p 5984:5984 -d couchdb:2.3.1