2002/08/28
前提
この段階で読者は Plan9 端末の運用にある程度慣れている事を想定する。
特に /lib/ndb/local の設定によって
1. ネームサーバの設定
2. ホストの IP アドレスの設定
ができると仮定する。
この端末はディスクベースで運用されていたはずであるので、その事も前提にしよう。
さて現在運用している Plan9 端末を認証サーバに変更する事を考えよう。目標は
以下は筆者のメモである。参考になるかも知れない。(sdC0 を使用している)
term% cd /dev/sdC0 term% disk/prep plan9 9fat 0 20482 (20482 sectors, 10.00 MB) fs 20482 11876073 (11855591 sectors, 5.65 GB) swap 11876073 12031929 (155856 sectors, 76.10 MB) >>> d swap >>> p 9fat 0 20482 (20482 sectors, 10.00 MB) fs 20482 11876073 (11855591 sectors, 5.65 GB) empty 11876073 12016620 (140547 sectors, 68.63 MB) >>> a swap 11876073 12031928 ?end sector out of range >>> a swap 11876073 12016619 >>> a nvram 12016619 12016620 >>> p 9fat 0 20482 (20482 sectors, 10.00 MB) fs 20482 11876073 (11855591 sectors, 5.65 GB) ' swap 11876073 12016619 (140546 sectors, 68.63 MB) ' nvram 12016619 12016620 (1 sectors, 512 B ) >>> w ?warning: partitions could not be updated in devsd >>>この最後の warning は swap を使ったまま作業を行ったために発生したらしい。前もって swap を禁止しておくべきである。sawp の起動は
/bin/termrc で行われている。
9pcauth に変更する。しかし、いつでも 9pcdisk に戻せるようにするのがよい。カーネルの置き場所は 9fat が良いであろう。9fat:を実行すると
/n/9fatにカーネルが置かれているのが分かるであろう。例えば筆者の場合には
term% 9fat: term% ls /n/9fat /n/9fat/9load /n/9fat/9pc /n/9fat/9pccpu /n/9fat/9pcauth /n/9fat/9pcdisk /n/9fat/plan9.iniであるが、読者のものはこれとは異なるかも知れない。
9fat に 9pcauth が無ければ /386/9pcauth をコピーする。
FD の plan9.ini の中に次の行を入れる。
bootfile=sdC0!9fat!9pcdisk bootfile=sdC0!9fat!9pcauthこの行を入れる事によって、ブート時にどちらを使用するのかを聞いてくれる。
password authid authdomの入力を要求される。
password: XXXXXX authid: bootes authdom: aichi-u.ac.jpとしている。
/bin/termrc ではなく) /bin/cpurc が最初に実行される。/bin/cpurc の中には次の行がある。# run these instead of the above two if you are an auth server # also be sure to remove /rc/bin/service/il566 and tcp567 # # auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1] # aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth il # aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth tcp # auth/cron >>/sys/log/cron >[2=1] &この最後の4つのコメントを外す。
switch($sysname){
case ar
ip/ipconfig ether /net/ether0 add 202.250.160.122 $ipmask
aux/listen -d /rc/bin/service il
aux/listen -d /rc/bin/service tcp
if(test -e /n/kfs/adm) disk/kfscmd listen
case al
aux/listen -d /rc/bin/service il
aux/listen -d /rc/bin/service tcp
if(test -e /n/kfs/adm) disk/kfscmd listen
case hera
auth/keyfs -wp -m /mnt/keys /adm/keys >/dev/null >[2=1]
aux/listen -d /rc/bin/service.hera -t /rc/bin/service.auth il
aux/listen -d /rc/bin/service.hera -t /rc/bin/service.auth tcp
auth/cron >>/sys/log/cron >[2=1] &
ip/dhcpd
ip/tftpd
}
ここに hera が認証サーバの名称である。/rc/bin/service.heraを指定しているのである。
サービスの具体的に内容は listen の d オプションと -t オプションで指定されたディレクトリを見れば分かる。必ず見るべきである。(これらのディレクトリは UNIX の /etc/inetd.conf に相当する)
また
netstat -nを実行してみる事によって、実際に実行されているネットワークサービスがわかる。
cpu% auth/changeuser arisawaを実行する。
Password: XXXXXXXX Confirm password: XXXXXXXX assign Inferno/POP secret? (y/n) y make it the same as the plan 9 password? (y/n) y Expiration date (YYYYMMDD or never)[return = never]: Post id: User's full name: Kenji Arisawa Department #: User's email address: arisawa@aichi-u.ac.jp Sponsor's email address: user arisawa installed for Plan 9パスワードは9文字以上にしましょう。Plan9 のドキュメントには8文字以上と書いてあるが、8文字のパスワードは容易に解読されます。(もっとも管理者が解読可能と言う意味です。認証サーバの運用を正しく行えは
/adm/keys /adm/keys.whoに、bootes のキーで暗号化されて納められている。
これらのファイルは keyfs によって管理されており、認証サーバのコンソールから
/mnt/keysにアクセスすると、keyfs が解読した /adm/keys の内容がファイル形式で読み取れる。
cpu% ls /mnt/keys/arisawa key log secret status expireこのうち、secret は POPやIMAPなどの認証を行う場合に使用され、認証サーバのコンソールからは生のパスワードが見える。従って認証サーバの物理的な管理が必要である。(注: この問題は factotum と secstore によって解決されるはずである。)
ユーザの削除は
cpu% rm -rf /mnt/keys/aliceのようにファイルの操作として行う。
/lib/ndb/auth に
# hostid=bootes # uid=!sys uid=!adm uid=*となっているが、このコメントを外しておく。
認証サーバでは、特に tcp のサービスは可能な限り止めた方がよい。
Plan9 の認証方式は challenge/respose 方式である。この方式の利点はネットワークにパスワード情報(暗号化されたパスワードも)流さない事である。
Plan9 では生のパスワードを暗号化し DES キーとしている。これを認証サーバが保管し認証に使用している。この内容は認証サーバのコンソールから仮想ファイルとして
/mnt/keys/*/keyの中にを見ることができる。
Plan9 ではユーザの DES キーは bootes の DES キーによってさらに暗号化されているので、/adm/keys の内容が盗まれても容易には解読されないであろうがそれでも辞書攻撃などで bootes のパスワードが破られる可能性がある。