[Bug] What is the purpose of UNBOUND_UID and UNBOUND_GID, when you do not set anything else other than 1000 (default) in the container ? about unbound-docker HOT 11 CLOSED

Hi,

sorry for late reply...

The finer nuances of "truely rootless" vs starting as root and dropping privileges are lost on me, I'm afraid. Could you explain how "NOT truely rootless" would lead to greater attack surface here ... I mean we drop back to _unbound user... or am I missing something ?

As I see it DISABLE_SET_PERMS could be useful for new setups - e.g. start with root and do not worry about permissions until unbound config is ironed out, then switch to unprivileged UID/GID for "production".

That said, the latest seems to work for my setup now, without adding the group_add, which I needed previously.
What I tested:

...
environment:
  UNBOUND_UID: 1111
  UNBOUND_GID: 1111
...

Container starts and there seem to be no permission problems. Of course unbound files need to be chowned to 1111:1111.

Thanks for looking into it!

from unbound-docker.

Maybe you could have a look at the docker --user flag - here.
For now, I personally use the group_add directive from docker-compose, to add the _unbound user to a GID, inside the container.

For example:

image: madnuttah/unbound:latest
...
group_add:
  - 1234
...

I then set permissions to 660/770 for files/folders with UID/GID=1234 outside the container. Seems to work OK.

from unbound-docker.

Thanks for pointing this out. Yeah, you are absolutely right, I'll make it more clear in the documentation.

from unbound-docker.

May I also suggest, not using the default 1000 when building the container ?
Up to 999 is "reserved" for system accounts, services etc. Maybe use something in the 800s or 900s, so as to not colide with anything outside docker. Then the user can create this UID/GID outside docker and assign the permissions accordingly.

from unbound-docker.

May I can manage to get the GID/UID stuff running properly for changing the given IDs. I'll take a look in it.

Thank you again for your heads-up!

from unbound-docker.

Thanks again, it's very appreciated! I'll do some tests.

from unbound-docker.

Hey @shadarim, I've changed the texts and linked a known issue to your comment as a workaround.

Thank you.

from unbound-docker.

That commit enables the custom UID/GID feature by passing environment variables to the container besides the possibility to define build args.

from unbound-docker.

Hi, I'm on vacation right now. I'm gonna try to test this next weekend and let you know.

From quick glance at the script.. Not exactly sure what the point of DISABLE_SET_PERMS (and the whole if-else for that matter) is? Can you explain?

It creates the possibility to run as root if user: _unbound is not set, as you point out in the doc. So is it like a new feature?

from unbound-docker.

Hey there and thanks for your answer and interest still!

There will be folder permissions set on container start for the given env vars UNBOUND_UID and UNBOUND_GID if the env var DISABLE_SET_PERMS isn't set or is set to false. For permission actions, root permissions are needed, so the container initializes with root, sets permissions and starts Unbound with user _unbound then. For users which need a rootless container just like it was before, the env var disables the setting of permissions and starts the whole container including Unbound using the _unbound account, it will be UID/GID 1000 for compatibility reasons, though. A drawback or benefit (one can decide) is that if you don't set the user _unbound explicitly in your compose or run command, the container is executed completely under root. It's a special use case but this makes the image even more versatile in my opinion. That's the reason I don't mention it in my examples, the majority of users will run the container in the "SET_PERMS" mode.

Sorry for disturbing you on your vacation. I'll keep this open until then.

Hope you like it!

from unbound-docker.

I could imagine use cases where the container should be completely initialized and run rootless, so that's done already too, also the opposite 'rootful' usage.

Nice that it works for you, I'll close this then. Thank you again.

from unbound-docker.