OSの出自によって異なる「ユーザー」という概念ユーザーとパーミッションにみるLinuxの設計思想
第4回 ユーザーとパーミッションにみるLinuxの設計思想Windows 9xではないに等しいが、Windows 2000やLinuxには「ユーザー」という概念がある。しかし、両者の概念は似ているようで多くの点で異なっている。ユーザーの権限やファイルのアクセス権にも差異があり、Linuxへの移行時に戸惑うポイントの1つとなっている。
OSの出自によって異なる「ユーザー」という概念
|
Windowsに慣れた人が初めてLinuxを使うと、ユーザーの概念に戸惑うと思います。Windows NT／2000の経験があればもう少しスムーズに理解できるかと思いますが、Windows NT／2000とLinuxでもユーザーの概念には微妙な違いがあります。
■コンピュータをフルコントロールするDOS系OS
MS-DOSをベースに発展してきたWindows 3.1→Windows 95→Windows 98→Windows Me（以下Windows 9x）には、ユーザーという概念が希薄です。これは、出自が「パーソナル」コンピュータであることに起因しています。つまり、「そのコンピュータを使うユーザーは1人」という前提になっているのです。
しかも、そのユーザーはコンピュータに関して必要なことはすべて知っているという暗黙の了解がありました。もっとも、これはMS-DOSやWindows 3.1のころのことで、Windows 95あたりからコンピュータそのものに対する知識は必要とされなくなっています。
こうした「コンピュータのことをよく知っているユーザー」が、8086/5MHzなどという非力なマシンを使うとしましょう。すると、OSは余計なことはせずに、機械を隅から隅まで自由に使えるようにしておく必要があったわけです。これをいまに至るまで引きずっているのが、Windows 9xというわけです。
■マルチユーザーが前提だったUNIX系OS
翻って、Linuxが手本としたUNIXでは、当初から1台のコンピュータを複数の人間で使うことが想定されていました。この場合はコンピュータを占有できませんし、自分のファイルを他人に書き換えられては困ります。そこで、だれがそのコンピュータを使っているのかを区別するためにユーザーという概念が導入されたわけです。
それぞれのユーザーは、互いに独立してコンピュータを占有しているかのように使えます（これはどちらかというとTime Sharing Systemの範疇ですが）。作業領域は/home以下にユーザー名と同じディレクトリが用意されているのが普通で、ここを「ホームディレクトリ」と呼びます。ちょっとしたツールなどは、この下にbinやscriptなどといったディレクトリを作ってインストールします。ただし、ユーザーのだれもが使うアプリケーションはホームディレクトリではなく、システムにインストールします。これは後述するrootユーザーでないとできません。
ホームディレクトリもWindowsでは希薄な概念です。NTドメイン（およびActive Directory）を使ってプロファイルを作成すれば、各ユーザーの作業領域を設定できます。が、これもそれほど一般的ではありません（編注）。
| 編注：Windows NT／2000によるユーザーディレクトリ機能はサーバを必要とするものであり、Linuxなどのローカルなホームディレクトリとは多少概念が異なるともいえる。サーバ上のホームディレクトリをNFSでマウントさせるという運用に近い。 |
ユーザーの持つ「権限」
|
一口に「ユーザー」といっても、OSごとにさまざまな違いがあります。その差異が顕著に表れているのが、「権限」という概念です。Windows 9xしか触ったことがない人には分かりにくいかもしれません。
■全員平等・全員rootのWindows 9x
先に「Windows 9xはユーザーの概念が希薄だ」としましたが、実際にはWindows 9xにも「ユーザー」という概念はあります。といっても、ユーザーごとにデスクトップを切り替えるくらいのことしかできません。
Windows 9xでユーザーという概念を希薄化させている要因は、権限という概念が存在しないことにあるといえます。どのユーザーも対等の権限を持ち、システムのあらゆる部分を変更でき、他人のファイルでも自由に変更・削除できます。そもそも、他人のファイルかどうかを判断する仕組みを持っていないのでどうしようもないのですが……。
■ヒエラルキー構造のWindows NT／2000
Windows NTやWindows 2000では、もっとユーザーの概念が発達しています。ファイルシステムにNTFSを使えば、ファイル／フォルダ（ディレクトリ）単位でユーザーごとにアクセス権を設定できるので、他人に読まれたくないファイルはそのように設定できます。
ユーザーの権限については、Windows 9xから大きく前進しています。Administratorsグループに属していればシステムすべてを、Power Usersグループ（標準ユーザー）に所属していればアプリケーションのインストールをはじめとして、システムのほとんどを制御できます。Usersグループ（制限ユーザー）になると、変更できる設定はごく限られたものになり、アプリケーションのインストールすらできなくなります。
Windows NT／2000のユーザー権限の概念をまとめると、Administratorsを頂点とするグループのヒエラルキー構造があり、どのグループに所属させるかによってユーザーの権限を決定するというわけです。
■基本的には2種類しかないLinuxのユーザー
Linuxでは、ユーザーは2種類しかありません。システムのすべてをコントロールできるrootというユーザーと、それ以外の一般ユーザーです。一般ユーザーはすべて平等で、権限に差はありません。
権限という観点から見るとWindows NT／2000に比べてシンプルな構造ですが、より重要なことはファイルに対する考え方の違いでしょう。Windows 2000が標準でファイルを「Everyoneフルコントロール」として作成するのに対して、Linuxでは原則としてフルコントロールできるのは自分のみで、他人には読み取りの権限だけを設定した状態でファイルを作成します（編注）。その意味では、よりユーザーという概念を徹底しているといえます。
また、Windows 2000とは違った形ですが、「グループ」という概念もあります。これは実行権限というよりは、後述するようにファイルに対するアクセス権の観点からユーザーをまとめたものです。
| 編注：umaskの設定を変更すれば、この限りではない。 |
■rootとAdministrator
Windows 2000のAdministratorに相当するユーザーは、Linuxにおいてrootという名前になっています。伝統的にrootという名前になっていますが、正確にいえばユーザーIDとグループIDが共に「0」のユーザーです。この条件を満たしていれば、root以外の名前でもシステム全体を変更できます。rootの環境を変更し損ねるとえらい騒ぎになるので、adminなどといったユーザー名を用意して、そちらを使うこともあります。
いずれにしても、システムに変更を加えるときはrootとしてログインすればいいわけです……と、簡単にはいきません。現代的なUNIXでは、セキュリティ上の配慮からrootはコンソール以外からログインできないのが普通です。個人用途ならたいていコンソールから操作しているわけですが、サーバなどはネットワーク経由でメンテナンスすることも多々あります。これをくぐり抜けるため、ネットワーク経由の場合はいったん別のユーザーとしてログインした後、あらためてrootになって作業します。こうすればパスワードが2つ必要になるので、多少は安全になります。
一般ユーザーからrootになるときに使うのが、suというコマンドです。rootは別名Super Userなのでその略かと思うのですが、実際には「rootになるため」ではなく、「ほかのユーザーになるため」のコマンドです。引数（ユーザー名）を省略したときはrootになるというだけですから、substituteとか、Switch Userあたりが語源でしょうか。
設計当初からマルチユーザーでrootが存在していること、suコマンドがあること、この2点がUNIXでのユーザーという概念を自然なものにしています。このおかげでアプリケーションは、「ユーザーが動かしているときはそのユーザーが書き換え権限を持っているファイルシステムしか使わない」のが当たり前ですし、いちいちログインし直さなくてもすぐにrootになれます。
Windows 2000ではずいぶんユーザーの概念がしっかりしてきましたが、いまだにアプリケーションによってはAdministrator権限がないと動かせないものもあったりしますし、ユーザーを切り替えるにはいちいちログオフ／ログオンの操作が必要です（編注）。そこで、結局適当なユーザー名をAdministrator権限で登録して、それを使い続けるということになります。これではうっかりミスでシステムに重大な損傷を与えかねません。私自身もこうした使い方をしていますが、あまりお勧めできる方法ではありませんね。
| 編注：Windows 2000には、一時的に異なるユーザー権限でコマンドを実行するrunusコマンドや［別のユーザーとして実行］機能（［Shift］キーを押しながら右クリック）がある。これを利用すれば、「ある操作を行うときのみAdministrator権限を使う」ことも可能。 |
実は、Linuxでもずっとrootで作業していたのでは同じことがいえます。面倒でも、root以外のユーザーを作って、普段はそちらで作業するべきです。そうすれば、/でrm -rf *とタイプして真っ青になる、ということもかなり防げます。
第4回 ユーザーとパーミッションにみるLinuxの設計思想関野史朗
2001/10/2
ファイルのパーミッション
|
ユーザーやその権限と切っても切れない関係にあるのが、ファイルのパーミッションです。Windows 9x＋FATにはまったく存在しない概念ですが……。
■多彩かつ活用されていないWindows 2000
 |
| Windows 2000のアクセス権設定画面（NTFS使用時のみ）。サブフォルダ以下に対して設定を継承させることもできる |
Windows NT／2000は、NTFSを使えばかなり細かくファイルに対するセキュリティを設定できます。グループごとに、
の6種類のアクセス許可を個々に設定できます。できますが、これを活用しているというユーザーにはお目にかかったことがありません。企業の基幹業務で使うため、ガチガチに開発されたシステムならいざ知らず、パーソナル用途では大げさにすぎるのも確かです。
■シンプルかつ必要十分なLinux
Linuxにおけるパーミッションはシンプルで、読み取り（r）、書き込み（w）、実行（x）の3種類です。これを、
の3グループに対して別々に設定できます。
$ ls -l |
を実行すると出てくる文字の並び（-rwxr--r--など）の左から2番目以降（rwxr--r--など）がパーミッションの状態を表しています。左から順に所有者、グループ、そのほかで、それぞれ上記3種類の属性を持っているので9文字となります。rwxr--r--を例にすると、所有者は読み・書き・実行ができて（rwx）、グループとそのほかは読み出すだけ（r--）、ということになります。
パーミッションを変更するには、chmodコマンドを使います。引数としては、変更するパーミッションの指定とファイル名を必要とします。また、パーミッションの指定には2通りあります。
まずシンボリックに行うには、
とするのが基本です。具体例を挙げると、
$ chmod o+r .bashrc |
でそのほかに対して読み出しを許可します。
$ chmod go-rwx .bashrc |
とすれば、所有者以外に対して読み・書き・実行を禁止します。ただし、ユーザー本人が読み・書き・実行できるかどうかの設定を行っているわけではないので注意が必要です。
もう1つ、数値で指定する方法もあります。rwxをフラグとすれば、3bitあれば表現できます。これを8進法で表記すればいいわけです。例えば、
$ chmod 700 .bashrc |
とすると、ls -lで表示したときrwx------になります。所有者には読み・書き・実行を許可し、それ以外には禁止しています。グループに対して読み出しを許可するなら、
$ chmod 740 .bashrc |
とします（rwxr-----になる）。
言い換えると、r＝4、w＝2、x＝1として足し算した結果（0〜7）が指定すべき数字です。もちろん、所有者、グループ、そのほかをすべて一度に指定するので、3けたの数字になります。
ここで「ディレクトリに対してxのパーミッションは何の意味を持つのか」と疑問に思った方もいると思います。もちろん、ディレクトリを実行できるわけではありません。これは、そのディレクトリ以下に対するアクセス権を設定しています。これを禁止すると、そのディレクトリ以下がまとめて読み出せなくなります。
なお、グループの設定は/etc/groupの内容を書き換えることで行います。現在自分が所属しているグループを表示するには、groupsコマンドを使います。1人のユーザーが複数のグループに所属できるので、目的に応じてグループを分けておくといいでしょう。例えば、データのバックアップを取るためにテープデバイスにアクセスできるグループとを作っておくと、システムをバックアップするつもりでリストアしてしまうといったミスが防げます。
■気を付けたいset-user-id
もう1つ、便利な指定として「sパーミッション」があります。普通はあるコマンドを実行すると、そのプロセスは実行したユーザーのものになります。たいていはこれで問題ないのですが、たまにroot権限の必要なデバイスにアクセスするコマンドがあります（サウンド関係でよく見かけます）。こんなときにsパーミッションを指定しておくと、コマンドを実行したユーザーではなく、ファイルの所有者のプロセスとして起動します。コマンドをrootがインストールしてsパーミッションを設定しておけば、/dev/mixerなども自在にアクセスできるというわけです。
ただし、これはもろ刃の剣です。特に、だれが実行してもroot権限で動作するコマンドにセキュリティホールがあると深刻です。これを利用することで、第三者が簡単にroot権限を入手できるからです。セキュリティのことを考えると、root権限で動作するコマンドはなるべく少なくしておくべきです。例に挙げたサウンド関係なら、/dev/mixerはaudioグループに対して読み書きを許可しています。従って、サウンドを使うユーザーはaudioグループに追加しておけばいいわけです。こうすれば、サウンド関係のコマンドにsパーミッションを設定する必要がなくなります。