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.