「グループ」とLinuxの「許可モデル」で混乱
Linuxのグループとパーミッションの概念を理解しようとしているので、完全に混乱しています。私が唯一のユーザー、つまりスーパーユーザーである私のラップトップでは、テキストファイルのファイル権限を変更して（chmod + x）、実行可能にしたり、読み取り/書き込み権限を変更したり（chmod + /-rw）
しかし、私はグループの概念を本当に理解していません。私が収集したものから、グループは単なるユーザーの集まりです。 （しかし、それはユーザーが複数のグループに属することができることを意味しますか？）私が理解しているグループは基本的に、多数のユーザー（つまりグループ）に対してrwxパーミッションを簡単に設定/設定解除することを目的としています。
しかし、今これについて website 作者はこう言っています：
Linuxには、所有者、グループ、その他の3つのアクセス許可レベルがあります。所有者はファイル/フォルダを所有するユーザーです。グループにはファイルのグループ内の他のユーザーが含まれ、その他は所有者またはグループ内にない他のすべてのユーザーを表します。
それは、所有者（つまり、ファイルを作成した人のユーザーID）を持つファイルに加えて、そのファイルの「グループ所有者」もいることを意味しますか？そして、このグループは通常、ファイル所有者が属するグループの1つですか？
システムに3つのグループA、B、Cがあり、権限を設定したい場合はrw-、-wx、r-xそれぞれシステム上で？
上記の質問をすることは、Unixの「グループ」と「グループ許可」が何であるかについての私のメンタルモデルに欠陥があることを示している可能性が非常に高いです。
たくさんの記事を読んでみましたが、グループの概念とグループの許可を理解する上で、基本的な何かが欠けているようです。誰かが私に簡潔な説明をしたり、このトピックに関するいくつかのより明確な記事を紹介したりできますか？
しかし、私はグループの概念を本当に理解していません。私が収集したものから、グループは単なるユーザーの集まりです。 （しかし、それはユーザーが複数のグループに所属できることを意味しますか？）
はい、そうです。
私が理解しているグループは、基本的に、多数のユーザー（つまり、グループ）に対してrwxパーミッションを簡単に設定/設定解除できるようにすることを目的としています。
アクセス許可の設定がはるかに簡単になる1つの方法は、グループがシステム内に散在する多くのファイルまたはフォルダーにアクセスする必要がある場合です。
たとえば、新しいユーザーが参加する場合は常に、そうでない場合はそれらのファイルを1つずつ検索し、「ユーザーA、B、Cがアクセスできる場合、ユーザーDを追加する必要がある」などの推測を試みる必要があります。ただし、これらの権限にグループ名がリストされているだけの場合、それらを更新する必要はありません。代わりに、ユーザーをグループに追加するだけで完了です。
（ファイルのアクセス許可だけに限定されません。一部のシステムサービスは、個々のユーザーではなくグループへのアクセスを許可するように構成することもできます。ここと同じ利点があります。）
それは、所有者（つまり、ファイルを作成した人のユーザーID）を持つファイルに加えて、そのファイルの「グループ所有者」もいることを意味しますか？そして、このグループは通常、ファイル所有者が属するグループの1つですか？
はい。各ユーザーには「プライマリグループ」があり、新しく作成されたファイルはそのグループに属します。ただし、root以外のユーザーでも、chown/chgrpを使用して、現在所属しているグループに自分のファイルを再割り当てできます。
（例外があります。ディレクトリに「setgid」ビットが設定されている場合、その中に新しく作成されたファイルは、作成者ではなくディレクトリのグループを継承します。これはデフォルトでのWindows NTFSの動作方法に近いです。）
もちろん、この「グループオーナー」システムは、ファイルが一度に1つのグループしか持てない場合、少し制限があります。それについては次のセクションを参照してください。
システムに3つのグループA、B、Cがあり、システムにそれぞれアクセス許可rw-、-wx、r-xを設定する場合はどうなりますか？
次に、 "ACL"（アクセス制御リスト）と呼ばれる別の機能を使用します。これは、名前が示すように、アクセスを許可するユーザーとグループの任意のリストを指定できるようにします。
LinuxはPOSIX ACL形式をサポートしています。これは、ほとんどの場合、既存のモデルを直接拡張したものです。つまり、最初に既存の権限を次のように書き換えるとします。
user::rwx, group::r-x, other::---
これで、setfaclまたはchaclを使用して、3つのadditionalグループを次のように追加できます。
group:Family:rw-, group:Friends:-wx, group:Coworkers:r-x
混乱を避けるための注意： POSIX ACLは、従来のchmodと可能な限り互換性を維持しようとしますが、これは驚くべき機能につながります。 ACLをファイルに追加するとすぐに、ls -lの「グループ」フィールドに「マスク」と呼ばれるものが表示され始め、chmod g-wのようなコマンドは「所有者グループ」だけでなく、すべてのACLエントリ。
代わりにACLだけを使用できるのに、なぜLinuxまたはUnixでも「所有者/グループ/その他」の分類を使用するのですか？これは、この単純な分類がACLサポートよりも数十年前に行われたためです。
他のほとんどのオペレーティングシステムが当時行っていたように、Unixは当初、単純なアプローチを採用していました。これは、ディスクスペースの制約（許可ビットは2バイトに収まる）、および/または意図的な設計決定（Multicsは、当時、複雑なACLを使用していた可能性があります） 、しかしUnixの多くは意図的に簡略化されています）。
最終的にAPIは堅固なものになりました。新しいAPIを追加することはできましたが、既存の "chmod"は変更できませんでした。プログラムがすでに特定の方法で動作することを期待していたためです。 （OpenVMSも、ACLを追加した後でも、同様のパーミッションビットシステムを維持する必要がありました。）
それに加えて、残念ながら、これはすべてのUnixライクなオペレーティングシステム間で相互互換性のある唯一のシステムです。他の一部のUnix（たとえば、FreeBSD、Solaris）はまったく異なるACL形式を使用している場合がありますが、それ以外（UNIX）では、ACLをまったくサポートしていません。 allファイル保護がACLベースであるWindowsとも比較してください。
Linux/Unixグループの概念canは混乱を招きます。しかし、それを開梱してみましょう。
ファイルとディレクトリには、所有者とグループの両方（または、「グループ所有者」と呼びます）があります。これらには、rwxアクセス許可ビットの3つのセットがあります。さらに、setuid、setgid、stickyの3つの権限が追加されています。ファイルまたはディレクトリのユーザーとグループは、ユーザーとグループの内部識別子として機能する符号なし整数であるUIDとGIDとして内部的に保存されます。
システム内のユーザーにはUIDとGID（通常は/etc/passwdファイルで設定）があり、そのファイルのGID設定はユーザーのプライマリグループを示すために使用されます。さらに、ユーザーはより多くのグループに属している可能性があります（通常、/etc/groupファイルで構成され、システム内の各グループの追加ユーザーをリストします）。
idコマンドを使用すると、ユーザーのUID、GID、プライマリグループ、および追加グループを確認できます。これにより、コマンドを実行しているユーザーのこの情報がすべてリストされます。
ファイルまたはディレクトリにアクセスしようとすると、システムは許可ビットに基づいてアクセスを検証しようとします。特に、ユーザー、グループ、またはその他のビットを使用するかどうかを見ることから始めます。 UIDがファイルにアクセスするユーザーのUIDと完全に一致する場合、「ユーザー」ビットが使用されます。グループの場合、primaryグループがファイルのグループと一致するか、追加のグループ（idによって報告される）がそのグループと一致する場合、「グループ」ビットが使用されます。それ以外の場合、一致するものがなければ、「その他」のビットが使用されます。
ファイルのアクセス許可の意味はかなり単純です。rはファイルを読み取り用に開くことができることを意味し、wはそのファイルを書き込み用に開くことができる（したがって内容を変更する）ことを意味し、xはこのファイルを実行可能ファイルとして実行できることを意味します（バイナリかどうかにかかわらず）またはスクリプト。）
ディレクトリの場合、それはもう少し微妙です。 rは、次のことができることを意味しますlistそのディレクトリ内のファイル（たとえば、ls /path/to/dirを使用）、wは、そのディレクトリに新しいファイルを作成できる（またはそのディレクトリから既存のファイルを削除できる）ことを意味します。 xがディレクトリにない場合、そのディレクトリにxがなく、そのディレクトリ内のファイルを実際に開くことができない場合でも、そのディレクトリ内のファイルにアクセスするにはcdが必要です。それらが存在することを知っています。 （これにより、rを使用してxを使用せずにファイル名を一覧表示できますが、ファイルを開くことはできませんが、xを使用してrを使用せずに、名前がわかっている場合にのみディレクトリ内のファイルを開くことができます。 、ディレクトリ内のファイル名を一覧表示できないためです。）
ディレクトリに新しいファイルを作成する権限があると仮定すると、作成する新しいファイルにはユーザーが所有者となり、デフォルトではプライマリグループが「グループ所有者」になります。しかし、常にそうであるとは限りません！
以前にsetgidビットについて述べたことを覚えていますか？ directoryにsetgid入札セットがある場合（chmod g+s /path/to/dirで設定できます）、そのディレクトリで作成された新しいファイルは、プライマリではなくディレクトリ自体のグループを継承しますそれを作成したユーザーのグループ。さらに、そのようなsetgid対応のディレクトリの下に新しいサブディレクトリを作成すると、そのサブディレクトリでもsetgidビットが有効になります。 （これは、サブツリー全体のグループ継承プロパティを保持するために必要です。）
このディレクトリ上のsetgidビットのテクニックは、共有ディレクトリを実装するのに非常に役立ちます。これについては後ほど説明します。
もう1つの注目すべき点は、BSDファミリのUnixシステム（FreeBSD、NetBSD、OpenBSDなど）alwaysがディレクトリにsetgidビットが設定されていると動作することです。このように、ファイルの作成中にグループであることが通常、このグループの最も目立つ機能であるため、ユーザーのプライマリグループはあまり意味がありません。
もう1つの興味深い概念は「umask」です。これは、新しいファイルまたはディレクトリが作成されたときに「マスク」されるビットのセットです。 umaskコマンドを使用してシェルでumaskを確認できます。また、引数を指定してそのコマンドを使用して、現在のumaskを変更することもできます。一般的な値は、umask 002、umask 022、umask 027などです。
Umaskのビットはrwxビットを参照し、3つの8進数字は、許可モードのユーザー、グループ、およびその他のビットにマップされます。したがって、umask 002はユーザーとグループのすべてのビットを保持しますが（0はマスキングなしを意味します）、他のビットはwビットをブロックします（2はwです）。ユーザーとグループに書き込み可能なファイルを保持しますが、他の人が読める。一方、umask 027は、ユーザーのみが書き込み可能で、読み取り/実行のみ可能で、グループは書き込み不可で、他のユーザーはアクセスできません（7は、rwxのすべてをマスクすることを意味します。）
umaskは、新しいファイルが作成されるたびに使用されます。アプリケーションは通常、必要なアクセス許可を通常最も自由なの方法で指定するため、umaskはそれをより現実的なアクセス許可に制限できます。たとえば、通常のアプリケーションでは、ファイルが0666（rw-rw-rw-）権限で作成されることを要求しますが、umaskは少なくとも書き込み可能なビットを落とすことを期待しています。ディレクトリは通常、同じと想定して、0777（rwxrwxrwx）で作成されます。
では、これをどのようにまとめることができるでしょうか？
Red HatベースのLinuxディストリビューション（RHEL、CentOS、Fedoraなど）で通常使用されるセットアップは、かなり柔軟で、検討する価値があります。
作成されるユーザーごとに、同じ名前のグループも作成され（通常、ユーザーのUIDと一致するGIDで）、そのグループはそのユーザーのプライマリグループとして設定されます。そのグループはonly同じ名前のユーザーを含むことを意図しています。そのため、私のユーザーのファイルは通常、filbranden:filbrandenとして作成され、自分のプライマリグループがグループ許可ビットをゲートします。
グループは基本的にユーザー自体と同じなので、umaskは002に設定されます。これは、すべてのファイルとディレクトリがデフォルトでgroup-writableになることを意味します。
では、ディレクトリをどのようにロックダウンしてプライベートにするのでしょうか。単純です。「その他」の許可ビットを最上位ディレクトリから削除するだけです。たとえば、chmod 770 ~を使用する場合（または700も問題ありませんが、770は、プライマリグループが自分のグループであるため機能します）、他のユーザーはアクセスできませんanyホームディレクトリにあるファイルの数。上部のディレクトリ自体にxビットがないと、そのビットをトラバースできなくなるため、内部のファイルが「その他」のビットを読み取ったり実行したりすることは重要ではありません。
では、共有ディレクトリをどのように実装するのでしょうか。シンプル。まず、グループを作成し、そのプロジェクトで共同作業を行う予定のすべてのユーザーをこのグループに追加します。次に、そのプロジェクト用に1つ（または複数）のディレクトリを作成します。ディレクトリの「グループ所有者」を、作成したグループに設定します。最後に、これらのディレクトリでsetgidビットを有効にします。そのグループのすべてのメンバーは、それらのディレクトリにファイルを作成できます。それらはすべてumask 002を持っているので、それらが作成するファイルはグループ書き込み可能になります。また、最上位ディレクトリのsetgidビットにより、すべてのファイルは共有グループ（ユーザーごとのプライマリグループではなく）によって所有されます。これは、グループ内のユーザーが作成されたファイルを変更できることを意味します- その他のメンバーグループのこれらのファイルへの書き込み権限があるため。
これらの共有ディレクトリは、誰でも読めるようにする（「その他」のrおよびx権限をトップディレクトリに保持する）か、グループにプライベートにする（これらの権限を削除する）ことができます。
それが要点です。 Unix/Linuxのアクセス許可が通常どのように機能するかと、なぜこのように機能するかについての根拠。
もちろん、多くの警告があります。これらの設定の多く（umaskなど）は異なるセッションに存在しており、同期が取れていない可能性があります。ユーザーをグループに追加するということは、通常、変更を有効にするために再度ログインする必要があるということです。 setgid-bitが有効なディレクトリにファイルを作成すると、ディレクトリのグループが継承されますが、movingそのディレクトリへの既存のファイルは、通常、所有権を変更しません（したがって、 notであるグループ共有は、グループの他のメンバーによって変更可能です。）ファイルの削除に関するセマンティクスは、多少注意が必要な場合もあります。
最新のUnix/Linuxシステムは、ユーザー、グループ、ファイルの所有権の背後にあるすべてのロジックを保持しています。ただし、通常は、拡張ファイルACLなど、アクセス許可を適用するための追加のメカニズムも含まれています。これは、ディレクトリツリーへの読み取り/書き込みアクセスを許可する際にさらに細かく設定でき、上記の基本的なアクセス許可に関する多くの問題の影響を受けません。
はい。すべてのファイルとディレクトリには、所有者とグループがあります。コマンドllを入力すると、所有者とグループがリストされた現在のディレクトリ内のファイルのリストが表示されます。
それをシンプルに保ち、複雑さであなたを悩ませないようにする試み：
もし、するなら chown root:www <FILEPATH>所有者をrootに、グループをwwwに設定しています。
もし、するなら chmod 750 <FILEPATH>所有者権限を読み取り/書き込み/実行に設定し、グループ権限を読み取り/実行に設定し、その他の（全員）権限をなしに設定しています。
つまり、rootは完全なアクセス権を持ち、wwwグループの誰もがファイルを読み取り/実行できます。したがって、ユーザー「sarah」とユーザー「bill」をwwwグループに追加すると、それらのユーザーはファイルに対する読み取り/実行権限も持つことになります。
システムに3つのグループA、B、Cがあり、システムにそれぞれアクセス許可rw-、-wx、r-xを設定する場合はどうなりますか？
グループには権限を設定しません。各ファイル/ディレクトリに権限を設定してから、各ファイル/ディレクトリに所有者とグループを割り当てます。ユーザーをグループに入れると、そのグループがアクセス権を持つすべてのファイル/ディレクトリへのアクセス権がユーザーに付与されます。
システムに750の権限を持つ3つのファイルがあるとします。
index.html（ルート：A）
index.txt（ルート：B）
index.php（ルート：C）
所有者（ルート）は、すべてのファイルへのフルアクセス（読み取り/書き込み/実行）を持っています。
グループAの全員がindex.htmlを読み取り/実行できます（index.txtまたはindex.phpはできません）。
グループBの全員がindex.txtを読み取り/実行できます（index.htmlやindex.phpはできません）。
グループCの誰もがindex.phpを読み取り/実行できます（index.htmlまたはindex.txtはできません）。
ユーザー 'sarah'は所有者（root）でもグループA、B、Cでもないため、どのファイルにもアクセスできません。ただし、ユーザー 'sarah'をグループAおよびBに追加すると、彼女は、index.htmlおよびindex.txtに対する読み取り/実行権限を持っています（ただし、index.phpに対する権限はありません）。ユーザー「bill」をグループBおよびCに追加すると、ユーザーにはindex.txtおよびindex.phpに対する読み取り/実行権限が付与されます（index.htmlに対する権限は付与されません）。
https://linux.die.net/man/1/chown
https://linux.die.net/man/1/chmod