9.3. 権限の管理

Linux は完全なマルチユーザシステムです。このため、ユーザの権限に基づいてファイルやディレクトリに対する操作を制御するためにパーミッションシステムを提供することが必要です。このパーミッションシステムはすべてのシステムリソースとデバイスに対して適用されます (Unix システムではすべてのデバイスはファイルまたはディレクトリとして表現されます)。この原理はすべての Unix システムで共通ですが、特に興味深く比較的知られていない上級の使い方があるので、注意は常に必要です。

9.3.1. Owners and Permissions

ファイルとディレクトリには 3 種類のユーザ別に特定のパーミッションが付けられます。以下に 3 種類のユーザを挙げます。

所有者 (「user」の u で表記されます)。
所有グループ (「group」の g で表記されます)。これはグループに所属する全ユーザを意味しています。
その他 (「other」の o で表記されます)。

Three basic types of rights can be combined:

読み込み (「read」の r で表記されます)。
書き込み (または変更。「write」の w で表記されます)。
実行 (「eXecute」の x で表記されます)。

ファイルの場合、これらの権限は簡単に理解できます。すなわち、読み込み権限があれば、内容を読むことが可能です (コピーも可能です)。書き込み権限があれば、内容を変更することが可能です。実行権限があれば、内容を実行することが可能です (実行権限に意味があるのは対象がプログラムの場合に限ります)。

SECURITY setuid と setgid 実行ファイル

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

root が所有者の setuid されたプログラムは一貫してスーパーユーザとして実行されるため、この種のプログラムが安全で信頼できるプログラムか否かという点はとても重要です。実際、好きなコマンドを呼び出すために root が所有者の setuid されたプログラムを破壊することで、ユーザは root ユーザになりすまし、システムのすべての権限を掌握することが可能です。

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see 第 8.9.4 節「管理者権限の共有」).

ディレクトリは別のやり方で取り扱われます。読み込み権限があれば、そのエントリ (ファイルとディレクトリ) のリストを閲覧することが可能です。書き込み権限があれば、ファイルを作成および削除することが可能です。実行権限があれば、そのディレクトリを横断することが可能です (cd コマンドでそのディレクトリに移動できます)。ディレクトリの読み込み権限がなくてもディレクトリを横断できるならば、ディレクトリ内の名前を知っているエントリにアクセスすることが可能です。ただし、エントリの存在を知らないかエントリの完全な名前を知らない場合、そのエントリを見つけることはできません。

SECURITY setgid ディレクトリとスティッキービット

setgid ビットはディレクトリにも適用されます。setgid ビットが適用されたディレクトリの中に新しく作成されたアイテムは、作成者のメイングループを継承するのではなく、自動的に親ディレクトリの所有グループを割り当てられます。こうすることで、ユーザが同じ専用グループに所属する複数のユーザの間で共有されているファイルツリーの中で作業をしている場合、(newgrp コマンドを使って) 自分のメイングループを変更する必要がなくなります。

「スティッキー」ビット (「t」で表記されます) とはディレクトリだけに有効なパーミッションです。これは特に誰もが書き込み権限を持つ一時ディレクトリ (/tmp/ など) に使われます。すなわち、スティッキービットを付けられたディレクトリ以下に含まれるファイルの削除を制限できます。ファイルは所有者 (または親ディレクトリの所有者) だけが削除できるようになります。/tmp/ にスティッキービットがなければ、/tmp/ ディレクトリ以下にある他のユーザのファイルを誰でも削除できることになります。

以下はファイルのパーミッションを制御する 3 種類のコマンドです。

chown user file。これはファイルの所有者を変更します。
chgrp group file。これはファイルの所有グループを変更します。
chmod rights file。これはファイルのパーミッションを変更します。

権限の指定方法には 2 種類あります。それらの中でも、記号指定が最もわかりやすく覚えやすいでしょう。これは上で述べた文字記号を使います。ユーザのカテゴリ (u/g/o) に対する権限を (= で) 明示したり、(+ で) 追加したり、(- で) 取り除いたりできます。そんなわけで、u=rwx,g+rw,o-r 式は、所有者に読み込み、書き込み、実行権限を与え、所有グループに読み込み、書き込み権限を追加し、その他のユーザから読み込み権限を奪います。追加と削除によって変更されない権限はそのままです。「all」を意味する文字 a は 3 つのユーザカテゴリすべてを表現します。このため、a=rx はすべてのカテゴリのユーザに対して同じ権限を与えます (読み込みと実行権限を与え、書き込み権限を与えません)。

数値表記は各権限を値 (8 進数) で表現します。具体的に言えば、読み込みは 4、書き込みは 2、実行権限は 1 で表現します。権限を組み合わせるには組み合わせたい権限に対応する数字を合計します。ユーザの各カテゴリ (所有者、グループ、その他) に対して与える権限を同じ順番で連結して、それぞれの権限を表現します。

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

同じ原則に従って特別な権限を表す 4 番目の桁は先に説明した 3 桁の権限表記の前に付けます。setuid、setgid、sticky ビットがそれぞれ 4、2、1 に対応します。chmod 4754 は前に説明した権限に加えて、setuid ビットを設定します。

8 進数表記で権限を指定すると、対象のファイルに対するすべての権限が同じものに設定されます。すなわち、たとえば所有グループに読み込み権限を与えるなどの新しい権限を追加したい場合、8 進数表記は使えません。なぜなら、既に設定されている権限を考慮した新しい権限の数値表記が対象のファイルすべてで同じ数値表記になるとは限らないからです。

TIP 再帰的操作

しばしばファイルツリー全体の権限を変更しなければいけない場合があります。chown、chgrp、chmod には、サブディレクトリ内で再帰的に操作を行うための -R オプションが用意されています。

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod o+x test.txt
  $ ls test.txt
  -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

GOING FURTHER umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.