root私のDuplicatiコンテナは 。これは、ファイルの生成とプロセスの実行の観点から非常に便利であり、混乱と不要な権限を最小限に抑えます。ただし、これは同じファイルシステム/OSにローカルにバックアップされたソースファイルにアクセスするときに意図しない副作用があります。これで、デフォルトではすべてのファイルにアクセスできません。それも素晴らしいですが...
...ファイルが異なるように生成されます。これは、さまざまなファイル（権限）構成を使用してファイルとディレクトリを作成するプロセス（カスタム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所有権、権限、およびACLをリカバリCAP_FOWNERできる必要があります。CAP_FSETID
Dockerには、コンテナの機能を設定するためのツールがあります。これがまさにこれらのツールの用途です。