ファイルモードビットの代わりにパスで許可

Question

この概念をファイルを含むディレクトリからデフォルトで権限を継承するより簡単な概念（おそらくインストールごと）に置き換える方法はありますか？

はい、デフォルトのACLと呼ばれます。

[root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask .
[root@ditirlns02 acl-test]# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

[root@ditirlns02 acl-test]# mkdir subDir
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# getfacl subDir/testFile
# file: subDir/testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# mkdir subDir/nestedDir
[root@ditirlns02 acl-test]# getfacl subDir/nestedDir
# file: subDir/nestedDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

これは面倒な例ですが、デフォルトのACLが作成時にサブディレクトリに継承され、ディレクトリとファイルに直接（有効なACEとして）適用されることを示しています。設計上、基本 ACL の変更は積極的に伝播されません。 Unixは可能な限り怠惰に努力するため、すでに存在するファイルに新しい権限を適用するには、操作setfaclやchmod魔法を使用することが期待されます。自動変更は望ましくない。誤ってファイルが広すぎるか、現在ロックされているアプリケーションの変更されたディレクトリの下にネストされた特定のディレクトリを管理者が考慮していないという話がよく聞こえます。

しかし、0777のウマスクは、このように限定されないところに大きな穴を開ける危険があります。

まあ、これは最初のポイントと実際には関係ありませんが、POSIX ACLはこの問題も処理します。権限に関しては、ACLはユーザーシェルのumask設定よりも優先されます。実際、ACL は拒否権限をマスクし、umask は権限を付与せず、暗黙的な拒否が発生するため、連携して動作します。次のコマンドを使用して変更できますsetfacl。

[root@ditirlns02 acl-test]# setfacl -m m:r-x testFile
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r--

ご覧のとおり、私の個人アカウントのデフォルトDACが私を「rwx」に設定しても、私のアカウントはまだ「rx」のみを取得します。これは、ACL マスクがこのようなことを防ぐためです。他のデフォルトのACLエントリと同様に、デフォルトのACLマスクを管理することもできます。

[root@ditirlns02 acl-test]# getfacl afterMask
# file: afterMask
# owner: root
# group: root
user::rwx
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx       #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

「自動再計算なし」が実際に機能していることを確認できるように、以前のディレクトリに戻りました。

Again this won't work if people start moving files around

私は少し先に進んでいるので、これが理想的な行動ではない理由をすでに説明していますが、詳しく説明できます。デフォルトでは、デフォルトのACLを変更すると、ほとんど常に既に存在するACLを変更したいと思います。問題は、権限が何であるかを正確に予測するシステムを設計できないことです。これにより、他のセキュリティと信頼性の問題に直面します。

たとえば、

/srv/applicationX/shares/accounting/deftManeuverさまざまな市場で会社のパフォーマンスに関する独自の情報を含むフォルダがあり、特定の人だけがそのフォルダにアクセスできます。
/srv/applicationX/shares は Samba または NFS で共有され、会社全体で使用されます。
新しい部門が起動し、さまざまなグループメンバーシップを使用するには、共有ディレクトリにrwxを提供する必要があります。
これで、新しい部門は独自の情報にアクセスできるようになりました。さらに悪いことは、権限がこのように設定されているという事実さえ気付いていないということです。なぜならどんなことをしなければならなかったのか1年が過ぎたから、deftManeuverそれが存在するという事実さえ忘れてしまったからです。

これはやや極端な例ですが、ポイントをよく示しています。権限がそのまま維持されている場合、プラットフォームは少なくとも「いいです。使用される受け入れられるので、おそらく彼らはまだ自分が望むことにかなり近いでしょう。一方、Windowsの世界では、存在するかどうかわからないファイルへのアクセス制御を変更できます。

この方法でdeftManeuver一度に適切な制限を設定することができ、それをオンにする必要がある場合、プラットフォームは「ディレクトリabcとその子孫にxyzが欲しい」と明示的に話すように強制します。プラットフォームは、少なくともユーザーがそうしないという賭けをヘッジすることができます。再帰setfaclを実行しています。

この機能は職場生活で何度も役に立ちました。問題を解決するために、あまりにも多くのディレクトリを開いて、セキュリティ担当者が「いいえ、そうしないでください」と言って、移行中新しい何年も何十年も蓄積された累積情報以外のファイルの権限は安全ではありません。

編集（オプションのACL呼び状）

これは、POSIX ACLに実際の問題がないという意味ではありません。ここにリストされている反対意見は、モデル内で処理された機能やバグではない機能にすぎません。

一般的なPOSIX ACLの問題は表現力です。それでもrwxしか取得できませんが、ターゲティングでより多くの作業を行う必要があります。 Windows / NTFSは、理解できないもの（マスクなしの基本概念、ユーザー固有の削除権限など）など、権限にショットガンアプローチを取ります。 Unixのような「ファイル名がファイル名であれば意味がありません」ファイル名の保持"). ファイルが空であるため、"書き込み"または権限の添付などに縮小されますが、添付権限、権限の変更権限、所有権のインポート権限など、意味のある多くの項目が含まれています。

ユーザーごとまたはグループごとにマスクを設定できないなど、いくつかのマイナーな問題もあります。

[root@ditirlns02 acl-test]# setfacl -m m:g:testGroup:rwx .
setfacl: Option -m: Invalid argument near character 3
[root@ditirlns02 acl-test]#

したがって、特定の有効な権限がマスクを超えることを明示的に許可する方法はありません（通常のルールは必ずしもそうではなく、異なるユーザー間で長い解決策を決定するように強制するか、またはあまりにも緩いマスクを設定することを強制します）。通常、どのルートが使用されているかを推測してください。撮った…）

正直に言えばそうではありません。誰でも包括的で表現的で安全な方法で権限を処理します。

Answer 1