root我的 Duplicati 容器运行其自己的 UID/GID [使用 Linuxserver.io 映像]，而不是作为 运行。从文件创建和进程运行的角度来看，这非常有用，可以最大限度地减少混乱和不必要的特权。但是，这会对访问同一文件系统/操作系统上本地备份的源文件产生意想不到的副作用；默认情况下，它现在无法访问所有文件。这也很棒，除了...
...文件的创建方式不同。它们是由进程（也在来自自定义 Dockerfile 和公共注册表的容器中运行）创建的，这些进程通过许多任意的、不同的文件（权限）配置创建文件和目录。
在完美的世界中，Duplicati UID 将简单地位于所有源文件创建进程使用的所有组中。但某些进程、容器等使用奇怪或无法控制的UMASK、默认文件创建模式，甚至某些文件故意不具有超出用户所有者的可读权限。
那么我的问题是：我怎样才能继续在容器中作为自己的不同用户运行 Duplicati，但允许它像root在（本地）文件系统中一样运行以允许它备份所有文件？
显然，我可以chown在每次运行之前重新授予权限或文件，但这可能会破坏某些仅在存在某些权限时运行的应用程序，或者破坏其他安全最佳实践。
编辑 2022-08-09 17:58 (UTC+1):感谢@telcoM，我创建了一个custom-cont-init.d脚本（由我正在使用的 Linuxserver.io 容器提供）：
apt update && apt install -y libcap2-bin && apt clean
setcap cap_dac_override=+ep /usr/bin/mono-sgen
cap_dac_override我现在可以使用以下命令看到流程中点亮的适当功能getpcaps：
root@dc42a0e3e0d7:/# ps auxnww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
0 1 0.0 0.0 200 28 ? Ss Aug08 0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service
0 16 0.0 0.0 204 16 ? S Aug08 0:00 s6-supervise s6-linux-init-shutdownd
0 18 0.0 0.0 196 4 ? Ss Aug08 0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -c /run/s6/basedir -g 3000 -C -B
0 27 0.0 0.0 204 20 ? S Aug08 0:00 s6-supervise s6rc-oneshot-runner
0 28 0.0 0.0 204 20 ? S Aug08 0:00 s6-supervise s6rc-fdholder
0 35 0.0 0.0 180 4 ? Ss Aug08 0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 -i data/rules -- /package/admin/s6/command/s6-sudod -t 30000 -- /package/admin/s6-rc/command/s6-rc-oneshot-run -l ../.. --
0 471 0.0 0.0 204 20 ? S Aug08 0:00 s6-supervise duplicati
20031 473 0.0 0.1 146324 14756 ? Ssl Aug08 0:00 mono Duplicati.Server.exe --webservice-interface=any --server-datafolder=/config --webservice-allowed-hostnames=*
20031 481 17.6 2.1 2273276 175044 ? Sl Aug08 249:35 /usr/bin/mono-sgen /app/duplicati/Duplicati.Server.exe --webservice-interface=any --server-datafolder=/config --webservice-allowed-hostnames=*
0 501 0.0 0.0 6872 492 pts/0 Ss+ Aug08 0:00 /bin/bash
0 1278 0.0 0.0 7040 3556 pts/1 Ss 17:33 0:00 /bin/bash
0 1315 0.0 0.0 8468 2796 pts/1 R+ 17:52 0:00 ps auxnww
root@dc42a0e3e0d7:/# cat /config/custom-cont-init.d/
21-extra-group-id 31-setcap-dac-override
root@dc42a0e3e0d7:/# cat /config/custom-cont-init.d/31-setcap-dac-override
apt update && apt install -y libcap2-bin && apt clean
setcap cap_dac_override=+ep /usr/bin/mono-sgen
root@dc42a0e3e0d7:/# getpcaps 471
471: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+ep
root@dc42a0e3e0d7:/# getpcaps 473
473: = cap_dac_override+ep
root@dc42a0e3e0d7:/# getpcaps 481
481: = cap_dac_override+ep
虽然我的第一个较小的备份测试没有任何以前的文件系统权限错误，但我仍然为更大/更慢的备份获取它们。为了让这个按照我希望的方式工作，我还缺少什么吗？
编辑 2022-08-30 13:09 (UTC+1)：接受的答案可能有效，但不适合我。我在 Docker Swarm 上运行这个容器：The cap_add and cap_drop options are ignored when deploying a stack in swarm mode它来自Docker Compose 参考文档。
答案1
使用 Linux 功能可能可以最好地解决这个问题（请参阅 参考资料man 7 capabilities）。
对于备份作业，CAP_DAC_READ_SEARCH可能足以允许它读取（从而备份）它可以看到的文件系统命名空间任何部分中存在的所有内容。对于恢复作业，您可能需要CAP_DAC_OVERRIDE能够在任何地方写入，CAP_CHOWN并且CAP_FOWNER能够CAP_FSETID恢复任何所有权、权限和 ACL。
Docker 具有允许您配置容器功能的工具：这些工具的用途就是像这样。