開発者ツール · Chmod 計算機
chmod と chown: モードの変更が間違った手段であることが多い理由
· なぜそれが重要なのか
chmod unix アクセス制御
モード ビットは、所有者とグループに関連するもののみを意味します。この投稿では 2 つのコマンドを分離し、エラーとプロセス ID からどちらが実際に必要かを判断する方法を示します。
2 つのコマンド、1 つのエラー — 権限拒否は今月 3 回、3 つの異なる chmod 行と chown 行で「修正」されました
chmod と chown は、どちらもパーミッション エラー近くに表示される場合でも、異なる情報に対応します。この計算機は、所有者、グループ、その他の許可ビットに加えて、特別なビットをモデル化します。現在の所有者またはグループを受け取らず、所有権操作も実行しません。したがって、モードは正しく変換される可能性がありますが、アイデンティティ関係は不明でテストされていません。
まず質問を分割します。 「750 では何が許可されますか?」は回答可能です。所有者は rwx を取得し、グループは r-x を取得し、その他は何も取得しません。 「これの所有者は誰ですか？」 「プロセスを実行するのはどの ID ですか?」外部証拠が必要です。 ID を解決する前にモードを編集すると、間違ったクラスが拡大される可能性があります。同期されたビューでは、chmod と所有権の変更のどちらかを選択できません。
最初に所有権、次にモード — カーネルがビットを確認する前にプロセスの所有者、グループ、またはその他を選択する方法
クラスの選択は ID に依存しますが、電卓は ID を決して受け取りません。その所有者、グループ、およびその他のトリプルはカテゴリであり、検出されたアカウントではありません。プロセスが所有者と一致するか、ファイルのグループに属するか、または他のグループに属するかを知ることはできません。 1 つの整数から 3 つの権限セットすべてを単純にレンダリングします。資格情報には外部検査が必要です。
したがって、アイデンティティは関連性を判断するための前提条件となります。モード 640 の場合、所有者は読み取りと書き込みを持ち、グループは読み取りを持ち、その他は何も持ちません。変換は確実ですが、該当するトリプルは確実ではありません。 UID、メンバーシップ、コンテナ マッピング、または ACL がこの状態にはなりません。まずこれらの事実を確立してから、対応するビットを評価します。
クラスの選択は ID に依存しますが、計算機は ID を受け取りません。
所有権ツールは所有者またはグループ関係を占有する人を変更し、chmod はそれらのクラスに関連付けられた権限を変更します。この計算機はchmod側のみを実装しています。 8 進数またはシンボリック chmod テキストを生成し、chown または chgrp を発行しません。また、ファイルは変更されません。パス フィールドは、外部レビュー用に引用されたプレビューのみを構築します。
モードを拡張すると、所有権を修正せずに追加のクラスを公開できます。 750 と 757 を比較します。後者では、他の読み取りと実行が追加されます。計算機にはそのデルタが表示されますが、別のアカウントの利益または所有権が失敗の原因であるかどうかはわかりません。所有者、グループ、プロセスのアイデンティティを外部で確立し、目的のクラスにのみ必要なビットを付与します。
共有グループ パターン — ディレクトリの chgrp と setgid に加え、書き込みが必要な 2 人のユーザーに対する標準的な回答として 2775
共有グループ ワークフローには、外部所有権ツールとポリシーが必要です。グループ書き込みが有効になっているため、プリセット 775 には「グループと共有」というラベルが付いています。プリセット 2775 は setgid を追加し、rwxrwsr-x をレンダリングします。ディレクトリの場合、新しいファイルはディレクトリのグループを継承します。これらのビットの説明は、完全なコラボレーション設計または展開の推奨事項を構成するものではありません。
このページでは、グループの作成、メンバーの選択、chgrp の実行、または 2775 がワークロードに適合するかどうかの確立を行うことができません。また、デフォルトの ACL、umask、またはアプリケーションの動作を検査することもできません。プリセットをポリシーではなく算術として扱います。他の場所で所有権とメンバーシップを解決し、環境証拠に基づいて実際の共有ディレクトリ設計を根拠にしながら候補モードを比較します。
共有グループのワークフローには外部所有権ツールとポリシーが必要です
他の場所で所有権を解決した後、ディレクトリ モード 750 を検査します。所有者は読み取り、書き込み、実行を受け取ります。グループは読み取りと実行を受け取ります。他は何も受け取りません。グループはリストを作成して入力することはできますが、エントリの作成、名前変更、削除はできません。計算機は、実際のディレクトリまたはアカウントを検査せずに、rwxr-x--- および u=rwx,g=rx,o= をレンダリングします。
通常のファイルについては 640 を個別に検査します。これは rw-r----- になります: 所有者は読み取りと書き込み、グループ読み取り、その他は何も行いません。このページには両方の結果が表示されますが、それらを再帰的に割り当てたり、展開アカウントを識別したり、サービス グループを選択したりすることはできません。 /var/www への適合性を主張するには、ここにないワークロードと ID の証拠が必要です。
有効な例: 所有権が別の場所で解決された後、750 と 640 を検査する
プロセス ID の検出は、このブラウザー ツールの外部にあります。 ps を呼び出したり、サービス構成を読み取ったり、コンテナーの名前空間を調べたり、アカウント データベースをクエリしたりするソースはありません。計算機は、実行中のアカウントまたは補足グループを識別できないため、どの権限クラスが操作を制御するかを判断できません。この分類には、責任のあるランタイムおよびファイルシステム環境からの最新の証拠が必要です。
外部で ID が確立されたら、関連するクラスを正確に確認します。プロセスがグループ アクセスを使用する必要がある場合、640 はそのクラスに読み取りを許可しますが、書き込みは許可しません。一方、660 はグループ書き込みを追加します。この算術は推奨されるものではありません。正しいビットは必要な操作によって異なります。ディスカバリーとポリシーをコンバーターの外に置き、表現ミスを防ぐために使用します。
プロセス ID の検出はこのブラウザー ツールの外部にあります
ACL とコンテナー UID マッピングは計算ツールにありません。そのモデルには 3 つの通常のクラスと特殊ビットが含まれていますが、名前付き ACL エントリ、マスク、名前空間変換は含まれていません。別の層がアクセスを制限している間はモードが十分であるように見えたり、ACL がそれを拡張している間は制限的であるように見えたりすることがあります。指定された整数だけではどちらの可能性も解決できません。
入力が欠落していると、診断と修復の両方が制限されます。ルートは、chmod、chown、ACL 変更、またはマッピング修正の中から選択することはできません。提供された基本モードをデコードし、s、S、t、T などの特殊文字をレンダリングできます。これを、サードパーティまたはコンテナーのアクセスに関する証拠ではなく、1 つの証拠レイヤーとして扱います。
要点: ビットの前に同一性を決定します。次に、Chmod 計算機を使用して、同一性が必要とするビット幅を正確に確保します。
ビットの前に同一性を決定します。モードは所有者、グループ、その他のクラスを通じて機能しますが、計算機は、それらを占有しているアカウントではなく、アクセス許可を認識します。外部検査によって所有権とプロセス ID が確立された後、候補を入力し、意図された読み取り、書き込み、および実行フラグをそれぞれ検証します。近くの値を比較すると、コマンドがブラウザーを出る前に誤って拡大してしまう可能性があります。
最終出力は提案のままです。このページは不正な入力を拒否し、8 進形式と記号形式を同期し、ファイルとディレクトリの意味を説明し、パスを引用し、chmod テキストを生成します。コマンドの実行、所有権の変更、ACL の評価、ポリシーの検査、アプリケーションのテストはできません。 ID を確立した後、担当システム上で提案された変更を検証します。