ファイル許可におけるユーザーおよびグループ所有者の優先順位
Linux（Arch Linux）でのファイルのアクセス許可に関して、予期しない（私にとっては）何かに遭遇しました。基本的に私は持っています：
userXingroupXfileX userX:groupX ---rwx----
私を困惑させるもの：rwxに対してアクション（fileX）を実行できません。これは正解？誰かがこれが実際に期待される動作であることを確認してください。
親ディレクトリへの書き込み権限があるため、実行できるアクションはmvとrmだけです。
問題は、これらのアクセス許可は、最も一般的なもの（その他->グループ->ユーザー）から始めて、お互いに折りたたまれると常に思っていました。つまり、o=rwxグループとユーザーの権限が何であるかを誰が気にしますか？明らかにそうではありませんが、私にはあまり意味がありません。直感に反するようです。このアプローチが役立つと思われる唯一のことは、非常に特定の人/グループを簡単に除外することです。さらに、所有者（およびグループ？）はとにかくchmodを実行できる必要がありますか？この問題についての考えは？
問題は、これらのアクセス許可は、最も一般的なもの（その他->グループ->ユーザー）から始めて、相互に折りたたまれると常に思っていました。
その場合は、「その他」の権限がすべてのユーザーに適用されます。
言い換えれば、o = rwxの場合、グループとユーザーの権限は誰が気にしますか？
それは前の文とは異なります。ここでは、権限が一緒にoredされていることを示しています。 userXがファイルを所有し、ファイルがユーザー読み取り可能である場合、またはuserXが属するグループがファイルを所有し、ファイルがグループ読み取り可能である場合、またはファイルが他の読み取り可能である場合、そのuserXには読み取り権限があります。しかし、それはそれが機能する方法ではありません。実際には、 o=rwxは、rwx権限が他のユーザーに適用されることを意味しますが、他のエンティティではないエンティティについては何も述べていません。
まず、ユーザーがどのグループに属しているかは直接関係ありません。カーネルには、グループに属するユーザーの概念はありません。カーネルが維持するのは、すべてのプロセスについて、ユーザーID（ 実効UID ）と グループID （実効GIDと補足GID）のリストです。グループは、ログイン時にログインプロセスによって決定されます。グループデータベースを読み取るのはログインプロセスです（例：/etc/group）。ユーザーIDとグループIDは、子プロセスによって継承されます。
プロセスが従来のUnix権限でファイルを開こうとすると、次のようになります。
- ファイルの所有ユーザーがプロセスの実効UIDである場合、ユーザー許可ビットが使用されます。
- それ以外の場合、ファイルの所有グループがプロセスの実効GIDまたはプロセスの補足グループIDの1つである場合、グループ許可ビットが使用されます。
- それ以外の場合は、他の許可ビットが使用されます。
使用されるrwxビットのセットは1つだけです。ユーザーは他のグループよりも優先されるグループよりも優先されます。 アクセス制御リスト がある場合、上記のアルゴリズムは一般化されます。
- ファイルにプロセスの実効UIDのACLがある場合、それを使用してアクセスが許可されているかどうかが判別されます。
- それ以外の場合、プロセスの実効GIDまたはプロセスの補足グループIDの1つに対するファイルにACLがある場合、グループ許可ビットが使用されます。
- それ以外の場合は、他の許可ビットが使用されます。
マスクの影響を含むACLエントリの使用方法の詳細については、 ユーザーが複数のグループに属している場合のACLの優先順位 も参照してください。
したがって、-rw----r-- alice internsは、Aliceが読み書きできるファイル、およびインターンを除く他のすべてのユーザーが読み込めるファイルを示します。権限と所有権を持つファイル----rwx--- alice internsは、アリス（インターンであるかどうかにかかわらず）以外のインターンのみがアクセスできます。 Aliceはchmodを呼び出して権限を変更できるため、これはセキュリティを提供しません。それはエッジケースです。 ACLを備えたシステムでは、一般化されたメカニズムにより、特定のユーザーまたは特定のグループからアクセス許可を削除できます。これは、便利な場合があります。
各アクション（読み取り、書き込み、実行）のすべてのビットをor-ingするのではなく、単一のビットセットを使用すると、いくつかの利点があります。
- ACLを備えたシステムで、ユーザーまたはグループのセットから権限を削除できるという便利な効果があります。 ACLのないシステムでは、1つのグループから権限を削除できます。
- 実装は簡単です。複数のビットセットを組み合わせるよりも、1つのビットセットをチェックします。
- 関係する操作が少ないため、ファイルの権限を分析する方が簡単です。
¹ setuid またはsetgidプロセスが実行されると、これらは変更される可能性があります。これは当面の問題とは関係ありません。
具体的な権限は、具体的な権限よりも優先されます。
groupXのuserX
fileX userX：groupX --- rwx ----
あなたはファイルの所有者なので、所有者権限のみが付与されます。所有者には権限がありません。したがって、何もできません。ファイルの所有者でなく、グループメンバーでもない場合は、グループの権限が適用されます。
ウィキページのこのセクションを読んでください
https://en.wikipedia.org/wiki/File_system_permissions#Classes
-rwxrw----は、所有者には読み取り、書き込み、実行の権限があり、グループには読み取りと書き込みがあり、他のユーザーには権限がないことを意味します。
指定した権限により、グループ「groupX」にファイルの読み取り、書き込み、実行の権限が付与されます。グループ「groupX」のメンバーであるがファイルの所有者ではない場合、これらの権限が適用されます。
この場合、私はあなたが本当にファイルの所有者であると想定しています。所有者に設定された権限のみが適用されます。もちろん、所有者はファイルの権限を上書きまたは変更できます。しかし、グループはこれを行うことができません。たとえば、vimは、書き込み権限を持っていないが所有者であるファイルに書き込むかどうかを確認するプロンプトを表示します。
私は通常、権限を左から右に読んでいます。私は所有者ですか？はいの場合、所有者権限が適用されます。そうでない場合;私はグループのメンバーですか？はいの場合、グループ権限が適用されます。そうでない場合は、「その他」の権限が適用されます。
場合によっては、ファイルの所有者であることが役立ちますが、書き込み権限はありません。ファイルを誤って削除または変更することから保護します。個人的に、私がすべてのテンプレートファイルに権限400を設定しました。これは、誤ってテンプレートファイルを変更しないようにするためです。実行権限についても同様です。
ユーザーをグループに追加し、グループにディレクトリ（070）へのアクセス許可を与えることができました。その後、再起動後、フォルダーにアクセスできました。
グループを作成：Sudo groupadd groupname
ユーザーをグループに追加：Sudo gpasswd -a username groupname
ディレクトリ全体が正しいグループ所有権の下にあることを確認します（実行するグループ名の現在のメンバーである必要があります）：Sudo chgrp -R groupname directory_path /
フォルダにグループrwxのみを指定します（単にrwにすることもできますが、必要に応じて調整します）。Sudo chmod -R 070 directory_path
上記を行った後、必ずログアウトしてから再度ログインしてください。それでも機能しない場合は、マシンを再起動してください。これを行うことは私のために働いた。