Dockerfile: facilitate the use of unprivileged container

Hi knot team,

I was migrating my setup from bare knot-dns to container, and it fails due to the lack of an existing knot user inside the container. This user is created when we install the package (deb, rpm, ...) and for those who migrate their config and/or want to execute unprivileged containers, a default user should also be created in the image.

The proposed patch adds the user and apply correct rights on /rundir, for the purpose of unprivileged container.

If server.user is not present in the config, it still works, as root also has rights to create files, thanks to its superuser capabilities.

0001-Dockerfile-facilitate-the-use-of-unprivileged-contai.patch

Thanks for the patch. I have a few questions:

• Is it necessary to specify the group and user IDs (53)?
• Is it enough to chown /rundir only and not also /config and /storage?
• Is -b /rundir a good idea?

Is it necessary to specify the group and user IDs (53)?

It is required in order to have a stable ID across rebuild (eg. a new dependency that adds a new user). However, 53 is quite random (in fact that is the IDs reserved in Gentoo for knot)

Is it enough to chown /rundir only and not also /config and /storage?

You're right, I assumed /storage and /config was shared with the host, but this is in fact not always the case (only true in my test case).

Is -b /rundir a good idea?

A more conservative value would be /storage (packages use /var/lib/knot).

@nemunaire could you please test bf7e6322 patch?

I just realized that the fixed GID and UID are intentional

You did the rights corrections indeed, thanks. Just add a fixed UID/GID to have them stable across futures rebuilds.

47888ab5 ?

Tested. It works as expected.

Thanks!

closed via commit b3972451

mentioned in commit 9ffc0958

mentioned in commit b3972451