[目次へ][6章へ][7章へ][7.2へ] 最終更新：$Date: 2002/09/09 06:19:36 $
ささいな補正。パスワード伏せました。
■■ 7.1 アクセス権について考える
■■■ 7.1.1 UNIXのアクセス制御機構での調整
■■■ 7.1.2 UNIXサーバ上にアカウントがあるユーザ間で共有する場合
■■■ 7.1.3 UNIXサーバ上にアカウントがないユーザ間で共有する場合
■■■ 7.1.4 pserverでアクセス権を制御する
■■■ 7.1.5 管理ファイルが誰でも書き換え可能なの知ってる？
■■■ 7.1.6 管理コマンドの実行ユーザを制限しておこう
■■7.1 アクセス権について考える
何かを人と共有して使おうとすると、必ず権限ということを考えなければならなくなります。CVSの場合は、「ファイルへのアクセス権」を考えなければなりません。「ファイルへのアクセス権」とは、「どのファイルは読み書き（＋実行）して良くて、どのファイルはそうしてはいけないのか」という設定のことです。「読んでもいいけど、変更してはダメだよ」という場合もあります。CVSでそれを制御するには、UNIX（または他OS）のアクセス制御機構とCVS自体のアクセス制御機構の2つの機構が関わってくるので、話が複雑になっています。それぞれの機構に分けて話をしましょう。前者についてはUNIXの場合についてのみ説明します。Windows NTでリポジトリ・サーバを運用している場合でも、大きな違いはないでしょう（未確認）。
■■■7.1.1 UNIXのアクセス制御機構での調整
新規にモジュールを作成し、作業対象を共有する場合に問題になるのは、リポジトリ（本書の例では/home/cvsroot）への書き込み許可、各モジュール（リポジトリの下のディレクトリ）への読み書き許可、および、管理ファイルhistoryへの読み書き許可の3つです。最後の管理ファイルhistoryは、最近のcvsでははじめから666（-rw-rw-rw-）に設定されています【図7.1.1】。666になっていなければ、chmod 666 historyとして修正しておいてください。
【図7.1.1】CVSROOT/historyのアクセス権を眺める ▼ % ls -la /home/cvsroot/CVSROOT/history -rw-rw-rw- 1 mika users 7648 Aug 27 02:22 /home/cvsroot/CVSROOT/history ▲
本書の最初の方で、リポジトリを/home/cvsrootとして作り、説明に使ってきました。このリポジトリの所有者はどう設定されているのでしょうか？ 確か「とりあえず、自分の書き込み許可権だけでも出す」ように指示したと思います。この指示に従っていれば、自分が所有者になっているはずです【図7.1.2】。この状態でリポジトリに読み書きできるのは、自分（mika）とusersグループに所属する他のユーザだけです。
【図7.1.2】リポジトリのアクセス権を眺める ▼ % ls -la /home/cvsroot/ total 28 drwxr-xr-x 7 mika users 4096 Aug 22 23:21 . drwxr-xr-x 15 root root 4096 Aug 22 16:13 .. drwxrwxr-x 3 mika users 4096 Sep 5 16:35 CVSROOT drwxrwxr-x 2 mika users 4096 Aug 22 14:28 bintest drwxrwxr-x 2 mika users 4096 Sep 5 16:52 cvstest drwxrwxr-x 6 mika users 4096 Aug 22 14:29 cvstest2 drwxrwxr-x 2 mika users 4096 Aug 27 02:23 test ▲
最近のCVSは自動的に（各モジュールについてはimportコマンド実行時に、管理ファイルhistoryについてはinitコマンド実行時に）グループの読み書き許可を出すようになってるようです。リポジトリ自体については、リポジトリの作成者が気をつけておくしかありません。もちろんモジュールの新規登録は「第三者には許可を与えない」というのも1つのポリシーとして考えられますが、登録を許可するのであれば、chmod g+wしてグループが書き込めるように設定しておきましょう。
逆にグループの他のメンバーに読み書きされるのがイヤなら、chmodコマンドでリポジトリのアクセス権を変更する必要があります。あるいは、自分だけのグループを作って、chgrpコマンドでリポジトリのグループ所有権を、chgrpコマンドでそのグループに変えておくという手もあります...と、これはリポジトリを共有しない場合の話でした。では、共有する場合の話をしましょう。
■■■7.1.2 UNIXサーバ上にアカウントがあるユーザ間で共有する場合
リポジトリを編集する可能性のあるメンバーで構成されるグループを作って、リポジトリのグループ所有権をそのグループに設定する方法のが簡単です。
例えば、開発グループmoonがあって、メンバーがmika、aya、usakoの3人であるとします。まず、/etc/groupにmoonグループを追加します【図7.1.3】。
【図7.1.3】/etc/groupへ追加する行 ▼ moon:x:9000:mika,aya,usako ▲
/etc/groupは1行毎にグループの指定をします。コロン（:）で区切られたフィールドの1番目がグループ名、2番目がパスワード、3番目がグループの番号、4番目がメンバーでメンバーはカンマ（,）で区切って並べます。グループの番号は重複しないように設定してください。その後、リポジトリのグループ所有権をmoonに変更します【図7.1.4】。念のため、ディレクトリの下の下までグループを変更するように、再帰（-R）を指定してchgrpコマンドを実行します。
【図7.1.4】グループを変更する ▼ % chgrp -R moon /home/cvsroot ▲
リポジトリはどんな風になったでしょうか？ ls -laで見てみましょう【図7.1.5】。
【図7.1.5】リポジトリのグループは変わったかな？ ▼ % ls -la /home/cvsroot total 28 drwxr-xr-x 7 mika moon 4096 Aug 22 23:21 . drwxr-xr-x 15 root root 4096 Aug 22 16:13 .. drwxrwxr-x 3 mika moon 4096 Sep 5 16:35 CVSROOT drwxrwxr-x 2 mika moon 4096 Aug 22 14:28 bintest drwxrwxr-x 2 mika moon 4096 Sep 5 16:52 cvstest drwxrwxr-x 6 mika moon 4096 Aug 22 14:29 cvstest2 drwxrwxr-x 2 mika moon 4096 Aug 27 02:23 test ▲
本当に他のユーザが読み書きできるようになったかどうか試してみましょう。ちょっと、usakoさんに、cvstestを取り出して、test.txtを編集・コミットしてもらいます。リポジトリのcvstestモジュールの状態を見てみましょう【図7.1.6】。
【図7.1.6】cvstestモジュールはどうなったかな？ ▼ % ls -l /home/cvsroot/cvstest total 24 -r--r--r-- 1 mika moon 9095 Aug 20 22:11 fish.jpg,v -r--r--r-- 1 mika moon 531 Sep 5 16:50 rcskeytest2.txt,v -r--r--r-- 1 mika moon 823 Sep 5 16:42 rcskeytest.txt,v -r--r--r-- 1 usako animal 326 Sep 5 17:24 test.txt,v ▲
test.txt,vだけ所有者がusakoに（また、グループがanimalに）変わっています。グループについては、ユーザの第一グループ（/etc/passwdに記述されたグループ）になってしまうので、新しくディレクトリを作成する場合にはリポジトリ内のディレクトリのグループを変更しておく必要があるでしょう。
ちなみに、所属するグループが違うユーザがディレクトリを作った場合、そのグループに属さないユーザがどのコマンドを実行しようとしても、CVSがロックファイルが作れず、コマンドを実行できなくなってしまいます。例えば、usakoおよびmikaがリポジトリ内にディレクトリを作成した結果、所属グループが入り混じってしまったとしましょう【図7.1.7】。
【図7.1.7】違うグループのディレクトリが含まれてるぞ ▼ % ls -l /home/cvsroot/cvstest2 ls -l /home/cvsroot/cvstest total 32 drwxrwxr-x 2 usako animal 4096 Sep 5 20:40 dir1 drwxrwxr-x 2 mika users 4096 Sep 5 20:41 dir2 -r--r--r-- 1 mika moon 9095 Aug 20 22:11 fish.jpg,v -r--r--r-- 1 mika moon 531 Sep 5 16:50 rcskeytest2.txt,v -r--r--r-- 1 mika moon 823 Sep 5 16:42 rcskeytest.txt,v -r--r--r-- 1 usako animal 326 Sep 5 17:24 test.txt,v ▲
この状態でusakoがupdateコマンドを実行してみた例が【図7.1.8】です。
【図7.1.8】usakoで更新してみよう ▼ [usako]% cvs update cvs update -P -d cvs update: Updating . cvs update: Updating dir1 cvs update: Updating dir2 cvs update: failed to create lock directory for `/home/cvsroot/cvstest/dir2' (/home/cvsroot/cvstest/dir2/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository `/home/cvsroot/cvstest/dir2' cvs [update aborted]: read lock failed - giving up ▲
cvstest/dir2というディレクトリは所有者がmikaに、グループ所有権が（mikaの所属する）usersになってしまっているので【図7.1.7 5行目】、ユーザusakoがcvstest/dir2を更新しようとしたときに、ロックファイルが作れないというエラーが表示され【図7.1.8 6-7行目】止まってしまいます【図7.1.8 8行目】。ロックファイルを作らないように-pオプションを使って標準出力に出させるという手もありますが、ファイルがたくさんあったりすると面倒です。
リポジトリの利用者にディレクトリ追加後はちゃんと設定するように注意しておいても、ついうっかり忘れることはあるでしょう。このようなことが起こらないようにするために一番簡単な方法は、/home/cvsroot、もしくは共有することがわかっているディレクトリを共有グループにした上でset-group-IDを設定しておくことです。
ごちゃごちゃ言ってもわかりませんね。 実際にやってみましょう。
【図7.1.8】set-group-IDの設定 ▼ % chmod g+s /home/cvsroot % ls -la /home/cvsroot total 28 drwxr-sr-x 7 mika moon 4096 Aug 22 23:21 . drwxr-xr-x 15 root root 4096 Aug 22 16:13 .. drwxrwxr-x 3 mika moon 4096 Sep 5 16:35 CVSROOT drwxrwxr-x 2 mika moon 4096 Aug 22 14:28 bintest drwxrwxr-x 4 mika moon 4096 Sep 5 20:48 cvstest drwxrwxr-x 6 mika moon 4096 Aug 22 14:29 cvstest2 drwxrwxr-x 2 mika moon 4096 Aug 27 02:23 test ▲
まず、set-group-IDを設定するには、chmodコマンドにg+sを指定して実行します。【図7.1.8】の1行目がそうです。2行目でls -laしてみると、drwxr-xr-xだった.（カレントディレクトリ）の許可属性が、drwxr-sr-xと変わっています。グループの許可属性中、実行に関する部分が、「x」から「s」に書き換えられたのです。
試しに、modetestモジュールを新しく登録してみます【図7.1.9】。modetestモジュールはファイルを1つとサブディレクトリを1つ持った単純なモジュールです。さらにサブディレクトリの中にもファイルが1つ入っています。
【図7.1.9】modetestモジュールを新規に登録してみる ▼ % cvs -d /home/cvsroot import -m "Mode test" modetest mikamama MODETEST1 N modetest/test.txt cvs import: Importing /home/cvsroot/modetest/dir1 N modetest/dir1/test.txt No conflicts created by this import ▲
登録後、ls -laで/home/cvsrootを眺めてみる【図7.1.10】ましょう。modetestだけ、set-group-ID が設定されています【16行目】。
【図7.1.10】/home/cvsrootを眺めてみる ▼ % ls -la /home/cvsroot total 32 drwxr-sr-x 8 mika moon 4096 Sep 5 21:45 . drwxr-xr-x 15 root root 4096 Aug 22 16:13 .. drwxrwxr-x 3 mika moon 4096 Sep 5 16:35 CVSROOT drwxrwxr-x 2 mika moon 4096 Aug 22 14:28 bintest drwxrwxr-x 4 mika moon 4096 Sep 5 20:48 cvstest drwxrwxr-x 6 mika moon 4096 Aug 22 14:29 cvstest2 drwxrwsr-x 3 mika moon 4096 Sep 5 21:45 modetest drwxrwxr-x 2 mika moon 4096 Aug 27 02:23 test ▲
さらに、modetestの中身をls -laRで再帰的に眺めてみる【図7.1.11】と、サブディレクトリにもset-group-IDが設定されています。そして各ディレクトリの中のファイルがグループmoonになっていて万々歳です。
【図7.1.11】/home/cvsrootを眺めてみる ▼ % ls -laR /home/cvsroot/modetest /home/cvsroot/modetest: total 16 drwxrwsr-x 3 mika moon 4096 Sep 5 21:45 . drwxr-sr-x 8 mika moon 4096 Sep 5 21:45 .. drwxrwsr-x 2 mika moon 4096 Sep 5 21:45 dir1 -r--r--r-- 1 mika moon 401 Sep 5 21:45 test.txt,v /home/cvsroot/modetest/dir1: total 12 drwxrwsr-x 2 mika moon 4096 Sep 5 21:45 . drwxrwsr-x 3 mika moon 4096 Sep 5 21:45 .. -r--r--r-- 1 mika moon 401 Sep 5 21:45 test.txt,v ▲
ということで、異なるグループに属するユーザ間でリポジトリを共有する場合には、共通のグループを作成し、リポジトリをそのグループに設定し、さらにそのリポジトリにset-group-IDを設定しておくとよい、ということになります。
■■■7.1.3 UNIXサーバ上にアカウントがないユーザ間で共有する場合
例えば、「開発者として参加して欲しいけど、サーバにログインする権限は出したくないなぁ」ということがあります。こういう時には、少々話が複雑になります。NFSでも、sambaでも、pserverでもどんな共有機構を使用しても、最終的にはシステム内に代理のアカウントを作成して、そのユーザの権限で読み書きをすることになります。システム内に個別のユーザを作成しないというポリシーがある場合には、NFSやsambaなどのファイル共有機構ではユーザ・アカウントを意味し、作業履歴が混乱するかもしれません。ログインすることのできない仮のアカウントを個別に作成して割り当てれば、混乱は避けれるでしょう。しかし、個別アカウントを作成すると、考えないといけないことが増えて管理者に大きな負担がかかります。
1つのアカウントのみを使い、CVS上での作業は区別できる環境を構築するには、pserverを利用するのが一番簡単だと思います。pserverが認証に用いるpasswdファイルにこのための機能が組み込まれています。
例えば、代理アカウントをfruitとし、外部開発者に渡すログイン名をそれぞれ、apple、orange、grapeとすることにしましょう。まず、【図7.1.12】のように実際にはログインできないユーザを作成します。
【図7.1.12】代理ユーザfruitの作成。 ▼ % /usr/sbin/useradd -u 8000 -g moon -d /tmp -s /bin/false -c "Proxy user for CVS" fruit % grep fruit /etc/passwd fruit:x:8000:9000:Proxy user for CVS:/tmp:/bin/false ▲
これは、RedHat Linuxのコマンドを利用しているので、各環境に合わせて適当にログインできないユーザを作成してください。3行目のように/etc/passwdファイルにエントリができていれば成功です。ここでは、先程のグループmoonを利用していますが、システムのユーザと共有しない場合は、代理となるグループを作成して、リポジトリのグループ所有権もその代理グループに設定します。
また、pserverは代理ユーザでしか使用しないという設定にしておけば、pserver自体を代理ユーザの権限で動かすこともできます（inetd、xinetdで設定します）。要はサーバ運用のポリシー次第ということです。このとき、管理ファイルpasswdは【図7.1.13】のように設定します（パスワードは伏せてます）。パスワード生成とpasswdファイルの扱いについては第6章を参考にしてください。
【図7.1.13】CVSROOT/passwd ▼ apple:xxxxxxxxxxxxx:fruit orange:xxxxxxxxxxxxx:fruit grape:xxxxxxxxxxxxx:fruit ▲
では、本当にappleとして作業できるのか、試してみましょう。まず、appleとしてpserverにログインする必要があります【図7.1.14】。
【図7.1.14】appleとしてlogin ▼ % cvs -d :pserver:apple@localhost:/home/cvsroot login Logging in to :pserver:apple@localhost:2401/home/cvsroot CVS password: ▲
次に、先ほど作成したmodetestモジュールをチェックアウトしてみます【図7.1.12】。
【図7.1.15】appleとしてチェックアウト ▼ [apple]% cvs -d :pserver:apple@localhost:/home/cvsroot checkout modetest cvs server: Updating modetest U modetest/test.txt cvs server: Updating modetest/dir1 U modetest/dir1/test.txt ▲
これをls -laで眺めてましょう【図7.1.16】。ファイルの所有者はmikaです。
【図7.1.16】modetestの状態 ▼ % ls -la modetest total 20 drwxrwxr-x 4 mika users 4096 Sep 5 22:18 . drwxrwxr-x 6 mika users 4096 Sep 5 22:18 .. drwxrwxr-x 2 mika users 4096 Sep 5 22:18 CVS drwxrwxr-x 3 mika users 4096 Sep 5 22:18 dir1 -rw-rw-r-- 1 mika users 32 Sep 5 21:52 test.txt ▲
しかし、cvs historyでCVSでのイベントを見てみると、ちゃんとappleがチェックアウトしたことになっています【図7.1.17】。
【図7.1.17】appleになって確認してみる ▼% ls -la modetest % cvs history O 2002-09-05 13:18 +0000 apple modetest =modetest= <remote>/* ▲
このように作業コピー上で作業している限り、全てappleが作業したことになります。そして、リポジトリ側ではそのファイルの作業者は代理ユーザ（fruit）がおこなったことになります。
ちょっと、ファイルを追加してみましょう【図7.1.18】。まず、test2.txtというファイルを作成し【図7.1.18 1-2行目】、それを追加【図7.1.18 3行目】、コミット【図7.1.18 6行目】します。
【図7.1.18】appleとして追加してみる ▼ % cat > test2.txt Test file by apple. % cvs add -m "Test file by apple" test2.txt cvs server: scheduling file `test2.txt' for addition cvs server: use 'cvs commit' to add this file permanently % cvs commit -m "New file addition test by external user" test2.txt RCS file: /home/cvsroot/modetest/test2.txt,v done Checking in test2.txt; /home/cvsroot/modetest/test2.txt,v <-- test2.txt initial revision: 1.1 done ▲
ここで、リポジトリにあるtest2.txt,vファイルを眺めてみる【図7.1.19】と、所有者は代理アカウントのfruitになっていることがわかります【図7.1.19 2行目】。
【図7.1.19】ファイルのユーザはどうなったかな？ ▼ % ls -l /home/cvsroot/modetest/test2.txt,v -r--r--r-- 1 fruit moon 240 Sep 5 22:24 /home/cvsroot/modetest/test2.txt,v ▲
しかし、historyコマンドのオプション-eを使ってCVSのイベント履歴を見てみる【図7.1.20】と、appleが追加したことになっています【図7.1.20 3行目】。
【図7.1.20】作業履歴はどうなったかな？ ▼% cvs history -e O 2002-09-05 13:18 +0000 apple modetest =modetest= <remote>/* A 2002-09-05 13:24 +0000 apple 1.1 test2.txt modetest == <remote> ▲
このように、システムとCVSとのユーザが入り混じって複雑ですが、良く理解して自分の環境にあったアクセス権を設定するようにしてください。
■■■7.1.4 pserverでアクセス権を制御する
7.1.1.3項のように、全て同じ代理アカウントを使用して作業する場合には、ユーザ毎にアクセス権を制御することが難しくなります。つまり、あるユーザには書き込み許可を出したくない、というようなことがあるかもしれません。別の代理アカウントを作って、システム側で書き込み権限を許可するのは大変ですし、ロックファイル作成にも問題が生じそうです。こんなときには、管理ファイルのreadersもしくはwritersを使用します。
例えば、orangeには書き込み許可を出したくないとします。readersでも、writersでもどちらを使ってもよいのですが、まずreadersを使う場合について見てみましょう。orangeだけ仲間外れに（書き込めなく）するには、【図7.1.21】のようにCVSROOT/readersにorangeと書きます。
【図7.1.21】CVSROOT/readers ▼ orange ▲
初期状態ではこのファイルはないので、【図7.1.22】のように登録しましょう。CVSはreadersを管理ファイルとして知っているので、checkoutlistに加える必要はありません。最後【図7.1.22 13行目】で、lsで存在を確認しています。
【図7.1.22】readersを追加する ▼ % cvs add -m "Readers file" readers cvs add: scheduling file `readers' for addition cvs add: use 'cvs commit' to add this file permanently % cvs commit -m "Readers file test" readers RCS file: /home/cvsroot/CVSROOT/readers,v done Checking in readers; /home/cvsroot/CVSROOT/readers,v <-- readers initial revision: 1.1 done cvs commit: Rebuilding administrative file database % ls /home/cvsroot/CVSROOT/readers /home/cvsroot/CVSROOT/readers ▲
次に本当に書き込めなくなったか、orangeになって作業してみます。そのためにはまずログインです【図7.1.23】。
【図7.1.23】orangeとしてログイン ▼ % cvs -d :pserver:orange@localhost:/home/cvsroot login Logging in to :pserver:orange@localhost:2401/home/cvsroot CVS password: ▲
さらに、orangeとしてチェックアウトした【図7.1.24】後、
【図7.1.24】orangeとしてチェックアウト ▼ [orange]% cvs -d :pserver:orange@localhost:/home/cvsroot checkout modetest cvs server: Updating modetest U modetest/test.txt U modetest/test2.txt cvs server: Updating modetest/dir1 U modetest/dir1/test.txt ▲
checkoutしたモジュールの作業コピー内に降りて【図7.1.25 1行目】、test.txtを編集したとします。これをコミットしようとする【図7.1.25 3行目】と、確かに怒られて書き込めませんでした【図7.1.25 4行目】。
【図7.1.25】orangeとして編集してコミット ▼ [orange]% cd modetest (test.txtを編集) [orange]% cvs commit -m "Modifing test by orange" test.txt cvs [server aborted]: "commit" requires write access to the repository ▲
同じ効果を、管理ファイルwritersでも実現することができます。こちらは、書き込み権限を持たせたいユーザだけを書いておくことで、それ以外のユーザの書き込みを禁止します。例えば、writersに【図7.1.26】のように書くと今度は、appleとgrapeが書き込めなくなります。
【図7.1.26】CVSROOT/writers ▼ orange ▲
ここでreadersを残したままだと、readersの方が優先されてしまい、この場合orangeも書き込めなくなります。次に、writersファイルのせいで、orange以外の人が書けなくなりますので、結局だれ一人として書き込めなくなります。困りましたね。こういう場合には、【図7.1.27】のようにreadersファイルを削除しましょう。
【図7.1.27】readersを削除する ▼ % cvs remove -f readers cvs remove: scheduling `readers' for removal cvs remove: use 'cvs commit' to remove this file permanently % cvs commit -m "Readers file removed" cvs commit: Examining . Removing readers; /home/cvsroot/CVSROOT/readers,v <-- readers new revision: delete; previous revision: 1.1 % rm /home/cvsroot/CVSROOT/readers rm: remove write-protected file `/home/cvsroot/CVSROOT/readers'? y ▲
注意して欲しいのは、removeコマンドだけでは、/home/cvsroot/CVSROOTにできたreadersは削除されないということです。システムのrmコマンドを使って削除しておきましょう【図7.1.27 10行目】。
このように、readersとwritersを両方使おうとするとややこしくなるので、どちらかを使うようにしておいた方がいいでしょう。どちらが少ないかということもありますが、readersの方が優先度が高いので、readersを使った方が間違いが少ないかもしれません。例えば、anonymous（匿名）アクセスを設定する場合には、readersに匿名ユーザを書くようにしましょう。
■■■7.1.5 管理ファイルが誰でも書き換え可能なの知ってる？
リポジトリを共有するように設定すると、書き込み許可を与えられたユーザであれば、リポジトリ内のすべてのファイルを書き換えられるようになります。これって、よく考えると結構怖いことだと思いませんか？ このあと紹介するように、いくつかの管理ファイルを設定すれば、CVSから外部プログラムを実行できるので、しようと思えばイロイロなことができちゃいます。開発者として登録した人に悪気がなくても、その人のシステムがクラックされてしまうかもしれません。用心するに越したことはありませんね。ここでは予想外の操作やクラックから大切な管理ファイルを守る手立てを学んでほしいと思います。
管理ファイルを特定のユーザにしかいじらせないためには、システムのグループ所有権を利用するしか方法がないようです。リポジトリ所有者だけが書き換えられるようにするには簡単です。管理ファイルのディレクトリCVSROOTから、chmod g-wでグループの書き込み許可を剥奪してください【図7.1.28】。これで、所有者以外のユーザは書き込めなくなります。
【図7.1.28】CVSROOTからグループの書き込み許可を剥奪 ▼ % chmod g-w /home/cvsroot/CVSROOT ▲
他のユーザ(たとえばusako)はロックファイルが作成できなくなるので、チェックアウトも困難になります【図7.1.29】。
【図7.1.29】usakoでチェックアウトしてみる ▼ [usako]% cvs -d /home/cvsroot checkout CVSROOT cvs checkout: Updating CVSROOT cvs checkout: failed to create lock directory for `/home/cvsroot/CVSROOT' (/home/cvsroot/CVSROOT/#cvs.lock): Permission denied cvs checkout: failed to obtain dir lock in repository `/home/cvsroot/CVSROOT' cvs [checkout aborted]: read lock failed - giving up ▲
実は、オプションを使えば読み込み自体は不可能ではないのですが、なんにしろコミットはできないということで良しとしましょう。管理者が複数いる場合には、その人たちをメンバーとするグループを別途作成し、CVSROOTをそのグループの所有とするのがいいでしょう。
■■■7.1.6 管理コマンドの実行ユーザを制限しておこう
本書では-kオプション以外説明しませんでしたが、CVSのコマンドadminは、実はリポジトリの状態を自由に変えられる凶悪なコマンドです。共有環境では、このコマンドの実行は必ず制限しておきましょう。まず、システムにcvsadminというグループを作ります。つまり、【図7.1.30】のような行を/etc/groupに追加しておくことをお勧めします。グループIDはなんでもいいので適当に選んでつけてください。
【図7.1.30】/etc/groupに追加する行 ▼ cvsadmin:x:9001: ▲
adminコマンドの使い方がよくわからないなら、このグループには誰も含めないようにすべきです。これで、adminコマンドは-kオプションを除いて誰も使えなくなります。-kオプションはcvsadminグループに入っていなくても誰でも使うことができます。心配しないでください。
さて、正しく制限されたかどうか、試してみましょう。ここでは、失敗しても影響の少ないState（状態）の書き換えで試してみます【図7.1.31】。cvsadminグループのメンバーに制限されている旨のメッセージが出て、無事（？）失敗しました【図7.1.21 2行目】。
【図7.1.31】制限されたかどうか試してみる ▼ % cvs admin -s 'Stab' cvstest cvs [admin aborted]: usage is restricted to members of the group cvsadmin ▲
adminコマンドで実際に何ができるのか知りたい人は、CVSの付属マニュアルを読むと良いでしょう。ただし、多くのオプションは昔との互換性を残すためだけに存在し、あまり実用的ではありません（凶悪なのはタグとロック関係くらいです）。