Run Docker container as non-root user

[robflate]

Is your feature request related to a problem? Please describe.

I'm running Backrest in Docker. When it writes new files in bind mounts /data, /config, /cache, /repos, all files are owned by root. When restoring files, Backrest creates a folder with the original file inside. The original file retains its correct owner/permissions but the folder Backrest places the backup in is owned by root.

Describe the solution you'd like

• Map my host user to a user inside the container with environment variables PUID and PGID so bind mounts (/data, /config, /cache, /repos) have the same owner as my host.
• Run Backups on files/folders in /userdata regardless of USER:GROUP and permissions. This would need to run as root or by giving the mapped user elevated permissions (--privileged, --cap-add, etc ??).
• Respect original file owner/permissions when restoring files regardless of USER:GROUP and permissions. This is currently the case but it would be good if the folder Backrest makes to write the restored file to is owned by the mapped user.
• Run commands inside the container that require elevated privileges (e.g. docker <container-name> stop) without getting permission denied. Either run as root or add the mapped user to the Docker group inside the container or by giving the mapped user elevated privileges.

It's common for a container to have an entrypoint.sh script that includes something like;

PUID=${PUID:-1000}
PGID=${PGID:-1000}

USER=abc
GROUP=abc

if [ "$PUID" == "" -o "$PUID" == "0" ]; then
	USER=root
	GROUP=root
elif ! $(id abc&>/dev/null); then
	groupadd -g $PGID $USER
	useradd -m -u $PUID -g $GROUP $USER
fi

Additional context

Ultimately, most containers don't need to run as root but something like a backup tool is different. There will very often be situations where you're backing up files not owned by a specific user or with restrictive permissions. However, maybe there are lots of things the container can just run as non-root? It feels safe to assume that /data, /config, /cache, /repos should be owned by the host user (PUID:PGID) and not root. Also, any services that don't need to run as root, shouldn't. On the other hand, access to /userdata would require root access or privileged access unless you could guarantee all files are owned by a specific user (often not the case and would probably lead to user confusion with lots of permission issues).

I lack the knowledge to understand how I can both run the Backrest container as a specific non-root user whilst also letting the container read/write data owned by different users (including root) that may also have restrictive permissions (600). I also don't understand the impact of this on running commands like docker <container-name> stop etc.

Hopefully this is simple without requiring granting any extended capabilities or privileges but I'm afraid that's beyond my understanding.

[robflate]

I've updated by post with additional information. It would be great to hear thoughts on this.

[garethgeorge]

Thanks for converting this into an FR and the detailed discussion of what you're trying to get done -- I think it makes sense for Backrest to try to adopt the UID= and GID= env vars convention established by linuxservers.io , we can definitely do something like this in a future release.

This issue might be an easy starter PR if anyone has interest in adding an entrypoint wrapper.

[robflate]

I found the Restic docs for running full backups without root. They're hidden away in the examples section;

https://github.com/restic/restic/blob/master/doc/080_examples.rst#full-backup-without-root

It suggests adding the extended attribute setcap cap_dac_read_search=+ep to the restic binary. Backrest would still also need to map the local user to the container with UID/GID env vars.

[danktankk]

has this been implemented yet by chance?

[garethgeorge]

It hasn't -- most of the work here is in testing the docker build and validating that permissions work correctly in a variety of contexts.

[awnumar]

Just to add some context to this, I believe this is the reason I'm not able to restore any snapshots running the Docker container on Unraid. I get the error

error: restore failed: restore snapshot "...:/backup/shared" for repo ...: command "/bin/nice -n 10 ionice -c 2 -n 7 /bin/restic restore --json ..." failed: exit code 1: restore failed
processing command output: no summary event found
Output:
cannot create target directory: mkdir /backup/shared/.DS_Store-backrest-restore-65d8f743: read-only file system

The mounted /backup folder is owned (on the host) by nobody in the users group (PUID=99, PGID=100)

[DetermineAbsurd]

@awnumar If you are using the default docker template from the community addons plugin for unraid, it mounts the backup directory as read only by default. You will have to change the mount to r/w.

[ajyey]

Another vote for this. I run backrest in a container and its a pain not being able to view the config or logs without chown'ing each time they're written to

[stefanorg]

+1 for me.

@garethgeorge I saw that there is already a feature branch garethgeorge/uidgid any plan to add it to main?

[ciotorcristian]

I think this feature is very important for the security of our systems. Any news on this?

[theacodes]

I'm happy to test this our or help out with a PR if needed, is this still something you're open to adding @garethgeorge ?

[spacecakes]

Just ran into this. Can't open the directories I restore because they are owned by root. Is there a fix or workaround?

[garethgeorge]

I'm happy to test this our or help out with a PR if needed, is this still something you're open to adding @garethgeorge ?

Yep -- this is something I'm open to supporting. Started work on this in #829 but haven't had time to prioritize finishing the impl and validating it. Happy if someone is interested to pick up the PR (or a better approach :) ).

[RikudouGoku]

Just ran into this. Can't open the directories I restore because they are owned by root. Is there a fix or workaround?

You can use the user: 99:100 variable and with UMASK:002 environment variable (on unraid). And the restored files will be owned by the user "nodoby" and with read & write access for owner and group but nothing for "others".

EDIT: Apparently it does not work IF the backup container ran as root. And the container for restore is non-root.