またユーザは1つデフォルトのグループID(GID / GroupIDentifier)がつけられています。
そのユーザIDやグループIDが条件に合致するかどうかでユーザに権限があるかどうかを判断しています。
<ref>
RED HAT ENTERPRISE LINUX Identity Management ガイド
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/identity_management_guide/index
</ref>
ファイルには、ユーザIDとグループIDが設定されています。
ユーザID＝このファイルの所有者です。
なお、本章の範囲では、所有者とユーザと同じ意味で使っています。尚、本章の範囲では、所有者とユーザと同じ意味で使っています。
ユーザが自分の所有するファイルの属性を変更し、そのファイルのアクセス権限などをコントロールすることができます。
ただしroot権限だけは例外で、システムのすべてに無制限にアクセスできます。
尚、ユーザIDが数字ではなくユーザ名として表示されるのは、ユーザIDはユーザIDが数字ではなくユーザ名として表示されるのは、ユーザIDは/etc/passwdで設定されている対応するアカウント名、
グループIDは/etc/groupで設定されている対応するグループ名に変換されて表示されるからです。
=== 読み込み / 書き込み / 実行 ===
基本的なファイルへのアクセス権限は、「読み込み」「書き込み」「実行」です。
-rw-rw---- 1 hironobu mail 0 Dec 9 19:39 hironobu
</pre>
-rw------- 1 hironobu hironobu 44 Sep 20 19:17 memo.txt
</pre>
ユーザ（所有者）、グループ、その他ユーザの読み取り許可・不許可、書き込み許可・不許可、実行の許可・不許可は3ビットで表すので、この部分を8進数で表現することもできます。
;考えてみよう: apacheはユーザwww-dataの権限で動作しています。cgi-binなどでコマンドを動かしファイルinfo.datに情報を書き込む必要があります。しかし、info.dataの中身に関してはセキュリティ上の問題のためユーザfoo以外には読ませたくありません(www-dataにも許可しません)。さて、この場合、info.datの適切なファイルの所有者、適切なパーミッションはどのようなものでしょうか。
=== プロセスのユーザIDとグループID ===
まずログインした時に、そのアカウント名に割り振られたユーザIDとグループIDの権限でログインシェルが動き始めます。
</pre>
=== 現在の権限管理 ===
古典的なUNIXはUIDとGIDだけで説明は済みますが、Linuxも含めBSD 4.3以降では、もっと複雑な設定ができます。
</pre>
=== 実行権限を限定させる ===
ruidがrootの時、つまりrootがファイルを実行した時は何でもできるので、euidをプロセス内で制限なく変更できます。
もちろん、Linuxがコントロールが可能であることと、
アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。
アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生することはいうまでもありません。アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生する<ref>POS37-C. 権限の破棄は確実に行う 【[https://www.jpcert.or.jp/sc-rules/c-pos37-c.html JPCERT/CCサイトへ]】</ref>ことはいうまでもありません。 === なるべくrootでは動かさない運用 === まだセキュリティなどをあまり気にせず、サーバとして動作しているものは何でもかんでもrootで実行していた時期がUNIXにもありました。これの利点は、アクセスする先のファイルのパーミッションやroot権限でしかオープンできないポート番号など一々気にしなくてもかまわないという点です。しかし、万が一、このサーバプロセスが何かの形で乗っ取られてしまい侵入者が外部から任意のコマンドを動かすことが出来るなら、侵入者にシステムに対して万能の権限を持ってしまうことになります。現在では実行権限はなるべく絞る形で運用されています。たとえばhttpd(apache)は1つだけrootで稼働しポートのオープンや子プロセスを生成するといった処理をします。実際のHTTPリクエストに対する対応は別の権限を与えて実行しています。たとえば下の例だとapache/apacheの権限でプロセスを動作させています。万が一、外部から不当なコマンドが動かされる事態になっても、apacheのユーザ権限が及ぶ範囲でしか被害がありません。システムの書き換えなど重大なセキュリティ侵害からシステムを守り被害を最小限にできるようなシステムの設計にするのが現在の一般的な考え方です。 <pre class="bash">% ps -eo user,group,args | grep httpdroot root /usr/sbin/httpdapache apache /usr/sbin/httpdapache apache /usr/sbin/httpdapache apache /usr/sbin/httpdapache apache /usr/sbin/httpd</pre> == ディレクトリへの特殊な設定 ===== ディレクトリにsetgidビットを設定する === ディレクトリのグループにsetgidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。 <pre class="bash">$ ls -l合計 4drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:35 foo$ sudo touch foo/fileA$ ls -al foo合計 8drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:36 .drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..-rw-r----- 1 root root 0 12月 14 02:36 fileA</pre> この例は、fooというディレクトリがあり、そのディレクトリ下にコマンド touch を使いrootの持ち物である fileA を作成します。この時のfileAの所有者、グループともrootです。 <pre class="bash">$ chmod g+s foo$ ls -ld foodrwxrws--- 2 hironobu hironobu 4096 12月 14 02:36 foo$ sudo touch foo/fileB$ ls -al foo合計 8drwxrws--- 2 hironobu hironobu 4096 12月 14 02:37 .drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..-rw-r----- 1 root root 0 12月 14 02:36 fileA-rw-r----- 1 root hironobu 0 12月 14 02:37 fileB</pre> ディレクトリ foo に対しsetgid ビットの設定を行います。setgid ビットがセットされるとグループの"x"だった部分が"s"に変化します。次にコマンド touch で fileB を作成します。 ディレクトリのグループ hironobu がファイルに継承されて fileB の所有者は root グループが hironobu になります。 === ディレクトリにStickyビットを設定する === ユーザ(user)が読み書きできるディレクトリにStickyビットを設定した場合、そのディレクトリにどのユーザでもファイルを作成することができますが、ディレクトリから削除する場合、そのファイルの所有者(owner)しか削除できません。 <pre class="bash">$ mkdir temp$ ls -dl tempdrwxr----- 2 hironobu hironobu 4096 12月 14 03:12 temp$ chmod go+rwxt temp$ ls -dl tempdrwxrwxrwt 2 hironobu hironobu 4096 12月 14 03:12 temp</pre>
== ACL ==
UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも複雑な設定をすることが可能になります。UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも限定的な設定をすることが可能になります。
この状態でwww-dataユーザのみにfoo.txtの読み込みを許諾するとなると、グループを使う方法だとwww-dataとhironobuだけのグループを作り、そのグループを設定し、グループの読み込みを許可する、といったことをしなければなりません。しかしACLの機能を使えばwwwdataとhironobuだけのグループを作り、そのグループを設定し、グループの読み込みを許可する、といったことをしなければなりません。このWebサーバがアクセスしなければならないファイルの所有者がhironobuのユーザしか存在していないのならば、グループで運用するのも問題ありません。しかし、もし、hironobu以外にmasamiというユーザがいたならば、双方別々のグループを作りwww-dataのみに読み込みを許諾することができます。属性を設定にはコマンドsetfaclを使用します。dataを加えるといった方法が必要になります。もちろんこの方法はユーザが増えるたびにグループも増えます。
そこでACLの登場です。www-dataのアカウントのみを直接指定してアクセスを許すといった個別の対応ができれば、これまでのUNIXのアクセス権限の手法よりもシンプルに扱うことが出来るようになります。
=== ACLの設定 ===
openSUSE
<ref>
openSUSE ドキュメンテーショ 第9章 20 Linux におけるアクセス制御リストでのアクセス制御リストhttphttps://opensuse-man-jawww.berliosbelbel.deor.jp/opensuse-htmlmanuals_ja/cha.-security.-acls.html
</ref>
やRadHat
<ref>
Storage Administration Guide第19章 システム管理者のガイド 第5章 アクセス制御リストhttps://access.redhat.com/site/documentation/ja-JPjp/Red_Hat_Enterprise_Linuxred_hat_enterprise_linux/67/html/Storage_Administration_Guidesystem_administrators_guide/ch-acls.html</ref>やTurbolinux<ref>Turbolinux 11 Server: ユーザーガイド 第 40章Posix ACL（Access Control List）http://www.turbolinux.co.jp/products/server/11s/user_guide/c15067.htmlaccess_control_lists
</ref>
などのACLに関する運用ドキュメントが参考になります。