ファイル許可におけるユーザーおよびグループ所有者の優先順位

Linux（Arch Linux）でのファイルのアクセス権に関して、（私にとっては）予期せぬ何かに遭遇しました。基本的に私は：

• userX に groupX
• fileX userX:groupX ---rwx----

困ったこと：でアクション（rwx）を実行できませんfileX。これは正解？これが実際に予想される動作であることを誰かが確認できますか？

私が実行できる唯一のアクションがあるmvとrm私は親ディレクトリへの書き込み権限を持っているので。

問題は、これらの権限は、最も一般的な権限（その他->グループ->ユーザー）から始まって、互いに崩れると常に考えていたことです。言い換えれば、o=rwxグループとユーザーの許可が何であるかを誰が気にしているのでしょうか？どうやらこれは事実ではありませんが、私にはあまり意味がありません。それは直感に反するようです。このアプローチが有用であると思われる唯一のことは、非常に特定の人/グループを簡単に除外することです。これは賢明な方法ではないようです（imho）。それに、所有者（およびグループ？）はchmodとにかくできるはずです。この問題について何か考えはありますか？

問題は、これらの許可は最も一般的な許可（その他->グループ->ユーザー）から始まって互いに崩壊すると常に考えていました。

その場合、「その他」の権限が全員に適用されます。

言い換えれば、o = rwxの場合、グループとユーザーの権限が何であるかを気にしますか？

前の文とは異なります。ここでは、パーミッションが一緒になっていることを意味しています。たとえば、userXがファイルを所有し、ファイルがユーザー読み取り可能な場合、またはuserXが属するグループがファイルを所有し、ファイルがgroupである場合、userXには読み取りパーミッションがあります-読み取り可能、またはファイルが他の読み取り可能な場合。しかし、それはそれがどのように機能するかではありません。実際には、o=rwx意味rwxの権限が他の人に適用されますが、それは他の人ではないエンティティについては何も言いません。

まず、ユーザーがどのグループに属しているかは直接関係ありません。カーネルには、グループに属するユーザーという概念がありません。カーネルが維持するのは、すべてのプロセスについて、ユーザーID（有効なUID）とグループIDのリスト（有効なGIDおよび補足GID）です。グループは、ログイン時にログインプロセスによって決定されます/etc/group。グループデータベースを読み込むのはログインプロセスです（例）。ユーザーIDとグループIDは子プロセスに継承されます¹。

プロセスが、従来のUnixアクセス権でファイルを開こうとするとき：

• ファイルの所有ユーザーがプロセスの実効UIDである場合、ユーザー許可ビットが使用されます。
• それ以外の場合、ファイルの所有グループがプロセスの実効GIDまたはプロセスの補助グループIDのいずれかである場合、グループ許可ビットが使用されます。
• それ以外の場合、他の許可ビットが使用されます。

使用されるrwxビットは1セットのみです。ユーザーは、他よりも優先されるグループよりも優先されます。ある場合は、アクセス制御リストは、アルゴリズムは、上記の一般化されています。

• プロセスの有効なUIDのACLがファイルにある場合は、アクセスが許可されているかどうかを判断するために使用されます。
• それ以外の場合、プロセスの実効GIDまたはプロセスの補助グループIDのいずれかのファイルにACLがある場合、グループ許可ビットが使用されます。
• それ以外の場合、他の許可ビットが使用されます。

マスクの効果など、ACLエントリの使用方法の詳細については、ユーザーが複数のグループに属している場合のACLSの優先順位も参照してください。

したがって-rw----r-- alice interns、Aliceが読み取りおよび書き込みができ、インターンを除く他のすべてのユーザーが読み取り可能なファイルを示します。許可と所有権を持つファイル----rwx--- alice internsは、Alice以外のインターンのみがアクセスできます（インターンかどうかは関係ありません）。Alice chmodはアクセス許可を変更するために呼び出すことができるため、これはセキュリティを提供しません。それはエッジケースです。ACLを備えたシステムでは、一般化されたメカニズムにより、特定のユーザーまたは特定のグループから権限を削除できます。これは便利な場合があります。

各アクション（読み取り、書き込み、実行）のすべてのビットを論理和するのではなく、単一のビットセットを使用することには、いくつかの利点があります。

• ACLを備えたシステムで、ユーザーまたはグループのセットから許可を削除できるという便利な効果があります。ACLのないシステムでは、1つのグループから権限を削除できます。
• 実装がより簡単です。複数のビットセットを結合するのではなく、1つのビットセットをチェックします。
• 関与する操作が少ないため、ファイルの権限を分析する方が簡単です。

¹ _{これらは、setuidまたはsetgidプロセスが実行されるときに変更できます。これは当面の問題とは関係ありません。}

より限定的な許可は、限定的な許可よりも優先されます。

groupXのuserX

fileX userX：groupX --- rwx ----

あなたはファイルの所有者であるため、所有者権限のみが付与されます。所有者には権限がありません。したがって、何もできません。あなたがファイルとグループメンバーの所有者でない場合、グループ権限が適用されます。

wikiページのこのセクションをお読みください

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- 所有者には読み取り、書き込み、実行の権限があり、グループには読み取りおよび書き込みの権限があり、他のユーザーには権限がありません。

指定した権限により、グループに「groupX」権限が付与され、ファイルの読み取り、書き込み、実行が許可されます。あなたがグループ「groupX」のメンバーであるが、ファイルの所有者ではない場合、これらの許可はあなたに適用されます。

この場合、実際にファイルの所有者であると想定しています。所有者に設定された権限のみが適用されます。もちろん、所有者はファイルの権限を上書きまたは変更できます。ただし、グループはこれを行うことはできません。たとえば、vimは、書き込み権限はないが所有者であるファイルに書き込むかどうかを確認するプロンプトを表示します。

私は通常、左から右にパーミッションを読みます。私はオーナーですか？はいの場合、所有者権限が適用されます。そうでない場合; 私はグループのメンバーですか？はいの場合、グループの許可が適用されます。そうでない場合、「その他」の許可が私に適用されます。

場合によっては、ファイルの所有者であるが書き込み権限がないことが有用です。誤ってファイルを削除または変更することを防ぎます。個人的に、すべてのテンプレートファイルに許可400を設定しました。これは、誤ってテンプレートファイルを変更しないようにするためです。実行許可についても同じことが言えます。

ユーザーをグループに追加し、グループにディレクトリ（070）へのアクセス許可を与え、その後、再起動後はフォルダーにアクセスできました。

グループの作成：sudo groupadd groupname

ユーザーをグループに追加：sudo gpasswd -a username groupname

ディレクトリ全体が正しいグループ所有権の下にあることを確認します（実行するgroupnameの現在のメンバーでなければなりません）：sudo chgrp -R groupname directory_path /

フォルダーにグループrwxのみを指定します（rwのみで、必要に応じて調整します）：sudo chmod -R 070 directory_path

上記を実行した後、必ずログアウトしてからログインし直してください。それでも機能しない場合は、マシンを再起動してください。これを行うことは私のために働いた。