またユーザは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>
</pre>
=== 実行権限を限定させる ===
ruidがrootの時、つまりrootがファイルを実行した時は何でもできるので、euidをプロセス内で制限なく変更できます。
もちろん、Linuxがコントロールが可能であることと、
アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。
アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生することはいうまでもありません。アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生する<ref>POS37-C. 権限の破棄は確実に行う 【[https://www.jpcert.or.jp/sc-rules/c-pos37-c.html JPCERT/CCサイトへ]】</ref>ことはいうまでもありません。
=== なるべくrootでは動かさない運用 ===
apache apache /usr/sbin/httpd
</pre>
== ディレクトリへの特殊な設定 ==
=== ディレクトリにsetgidビットを設定する ===
ディレクトリのグループにsetgidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。
<pre class="bash">
$ ls -l
合計 4
drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:35 foo
$ sudo touch foo/fileA
$ ls -al foo
合計 8
drwxrwx--- 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 foo
drwxrws--- 2 hironobu hironobu 4096 12月 14 02:36 foo
$ sudo touch foo/fileB
$ ls -al foo
合計 8
drwxrws--- 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 temp
drwxr----- 2 hironobu hironobu 4096 12月 14 03:12 temp
$ chmod go+rwxt temp
$ ls -dl temp
drwxrwxrwt 2 hironobu hironobu 4096 12月 14 03:12 temp
</pre>
== ACL ==
UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも現敵的な設定をすることが可能になります。UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも限定的な設定をすることが可能になります。
openSUSE
<ref>
openSUSE 第15章 Linuxのアクセス制御リスト20 Linux でのアクセス制御リストhttps://www.susebelbel.comor.jp/jaopensuse-jp/documentation/sles10/book_sle_reference/datamanuals_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に関する運用ドキュメントが参考になります。