1. Introduction
◆ su 禁止
つまるところ UNIX に皮を被せたものである Mac OS X には、“ユーザ”と“ログイン”っていう概念があるんだ。そして“root”っていう概念もある。ある特定のファイルやディレクトリには root しか触ることができないんだ。しかし、classic の Mac OS にはそんな考え方がなかったので、普通のユーザはそんなことを気にしないだろう。機能拡張やコントロールパネルを外して楽しむように、/bin や /usr/sbin の下のファイルを外して、使用メモリを減らそうと試みるかもしれない。おぉぅ、それはやめてくれぇ。そんなことが流行りはじめたら、混乱を極めることは間違いないだろう。
そこで Apple がとった手段は、10.0 以降の Mac OS X では、デフォルトでの root でのログインを禁止することだった。Oh, my! これは英断と見るべきなのか、暴挙と見るべきなのか？さらにさらに、Apple は su までも禁止したのだった。su というのは、root の権限を得るためのコマンドね。Terminal で su を打つと、次のように表示されるんだ。
Welcome to Darwin!
[localhost:~] mkino% su
Password:
Sorry
[localhost:~] mkino%
|
root になろうとすると、ひとこと "Sorry"。クール過ぎるぜ！
さて、当然このままで終わるわけはなくて、Apple は別の手段を推賞している。それは sudo を使うこと。sudo を使うとコマンドを root 権限で実行することができる。su と違うのは、sudo はすべてのログが残る、ということらしい。つまり su だと、Telnet で侵入されて root になられて好き放題やられちゃうけど、sudo ならばその場合でもログが残るぜ、ということなのだ。うーん、あまり変わらんような気もするが。別の効用もあるのか？
◆ Permission denided を乗りこえる
じゃ、デスクトップ・アプリケーションを作るときのことを考えてみよう。この場合でも root 権限が欲しい場合がある。たとえばインストールの時とか、/usr/sbin の下のファイルを削除するときとか＜良い子はそんなことしちゃいかん。喜びいさんでやろうとすると、無情の Permission denided が表示されることになるだろう。やかましいわ、おれはこのマシンの所有者だぞ、一人で使ってるんだぞ、ネットワークにも公開してないぞ、だから好きにファイルをいぢらせろー、ぜぃぜぃ、はぁはぁ。と、文句をいっても解決しないのである。だって Mac OS X は UNIX だから。
現実的な解決策は、コマンドラインから操作しているならば sudo を使うことだ。これで root 権限が得られる。じゃ GUI ベースの場合は？Cocoa アプリならば sudo を NSTask で呼び出してもいいけど、めんどくさいよね。そこで Apple から提供されたのが Authorization API なんだ。これを使えば GUI ベースで楽々認証ができるんだぜ！
|
