/root所有者が使用できないとマークした理由に関する文書はありますか？ ( r-xr-x---)
CAP_DAC_OVERRIDE を使用すると、所有者は通常書き込みアクセス権を持っていることがわかります。ところがこれを見てまた驚いた。だからこれから何かを学ぶことができるのだろうか？
私にとって、Debian のアプローチはもっと自然に見えます。 Debian では権限がrwx------。
$ rpm -q --whatprovides /root
filesystem-3.2-37.fc24.x86_64
$ sudo dnf info filesystem | grep Release
Release : 37.fc24
$ grep ^VERSION= /etc/os-release
VERSION="25 (Workstation Edition)"
答え1
2009年頃、Fedoraはこれを変更しました。源泉：https://bugzilla.redhat.com/show_bug.cgi?id=517575P
この点を指摘してくれた@jordanmに感謝します。関連する引用をコピーしてみました。免責事項：このレンダリングで何かが失われたことは確実です。
これらの変更はルートから書き込み権限を削除するため、書き込みにはDAC_OVERRIDEも必要です。その後、rootが必要ですが、ネットワークまたはsetuid指向の機能を削除しました。
批判的な反応
とにかく善意のアイデアですが、実際にはuid 0ですが、CAP_DAC_OVERRIDE以外のプロセスはまだu + wを持つ/usr/bin/bashを完全に書き換えることができるため、追加の作業なしでは機能しません。または/root/.bashrc。この種の問題に対する答えはSELinuxです。 Recovery Catalog Mode 755パッチに異議がありますか？
著者の答え：
[あなたのソフトウェア]にどんな問題がありますか？システムディレクトリに書き込もうとすると問題があるのです。
返信：
これは大きな問題ではありません。 rpm-ostreeを効果的に復元するコードは、サイズが小さく、時間が経つにつれて持ち運びにくくなりません。
私はこの問題を経験している他の人が私たちがrpm-ostreeで行った変更を見ることができるように、これらのエラーを相互接続したいと思いました。
第三者哀悼：この問題を解決するためにクラスのすべてのツールに必要なパッチワークについてです。
https://github.com/projectatomic/rpm-ostree/pull/335
この問題を引き起こしたFedoraのバグに接続し、「作成」ケースでも機能するように変更します。理由は次のとおりです。
- 繰り返しますが、セキュリティを追加しません。
- 「作成」リポジトリで実行されるツールは、チェックアウト時にこの問題を解決する必要があります。https://lists.freedesktop.org/archives/xdg-app/2016-June/000241.html