サーバ上でのファイル管理はローカルで行ったもののミラーであるという時代は終わってしまったのかもしれない。最近のCMSなどに見られるように、コンテンツの実体はサーバ上に有、これを管理者が直接書き換えることが一般的になってきたと思う。この状態が進めば、Perlでかかれたプログラムとかもローカルテスト無しで動かす悪い奴が出てくるのかもしれない。かくいう僕もそんな悪い奴の一人。ごめんなさい。
テストが済んでいないcgiを共有サーバ上で実行することは禁止。しっかり規約に書いてあるけどね。これに対してファイルの移動、パーミッション変更、内容編集等を行うプログラム群が共有サーバ管理人から供給されているというのはどういうことなんだろう。規約を作るチームに当事者であるサーバ管理人が不在なんてことはないだろうから、管理人が了解した上で現行の規約が発行されているはずだよね。
僕は現にこうして共有サーバ上に原稿を上げているけど、共有サーバ使用者に対して共有サーバ管理人が僕らに供給してくれたファイルエディタを使った経験は少ない。だからよくわからないけど、多分上のようなサービスはシェル(移動、パーミッション変更)とテキストエディタ(内容編集)のようなものなんじゃないかと思う。Windowsで言えばエクスプローラとメモ帳だ。多くの無料共有サーバ管理者は、このようなサービスを供給しているし、このようなサービスを宣伝文句としても使っている。
ファイル編集が可能ということはcgiプログラムの編集も可能なのかもしれない。ならば、上のようなサービスは間違って編集されたプログラムをサーバ上で走らせること、ひいては規約違反を助長しているのではないだろうかと思った。
共有サーバ管理者がファイル編集や仮想シェル機能を僕らに供給している。telnet.cgiを設置することを禁止しているサーバ管理者もいる。そんな管理者でも、上のようなファイル編集プログラムを提供している。これらを踏まえて僕らが自分でこれらの機能を自分のサーバスペースに設置することは許可されるのか。
管理者のしたことは、管理者の作ったtelnet.cgiの供給に他ならないと思う。つまり管理人が認めたファイル編集動作のみを行うプログラムだ。perlで書かれたcgiが実際の無料共有サーバで許可されていることを考えると、僕らが自分達のサーバスペースに設置できるのはperlで書かれたcgiである。実際にperl単体でもパーミッションの変更、ファイルの移動、編集をになうプログラムは書くことができる。それだけでなく、外部サーバと通信するプログラムだってかける(通信機能はサーバ管理者によって使えないようにされていることのほうが多い)。重要なのは、perlプログラムが万能でも管理者がperl自体の機能を制限することでプログラムの機能を制限できてしまうという点だ。
共有サーバのユーザーは当然管理人の認めた環境のもとでプログラムを動かさねばならない。だから、高負荷なプログラム、例えば1兆回のループや1秒間にクライアントと100回通信するようなプログラム、でなければどんなものも設置可能だと思う。つまり、ディレクトリの内容を表示するだけのlsコマンドをエミュレートするcgiプログラムを禁止する理由はどこにもないはずである。cgiがどのような権限で走らされるのかは管理者が決めることである。もし、ls /とかの入力に対してルートの内容を表示させられたくなければ、管理者はそれ相応の対処方法を知っていてしかるべきである。
サーバ管理者はユーザの挙動を管理して自分のサーバが破壊されないように守ることが仕事である。ゆえに、言うことを聞かないユーザーをアカウント停止処分も仕事の内だ。ただしこれが管理者のスキル不足によるものであったとしたら、なんともお粗末なものである。高負荷やセキュリティハックの危険性を未然に防げないことは、管理者の責任でもある。僕は一般に管理者はskillfulな人間だと思っているし、そうであってもらいたい。僕らは管理の下で許可されていることなら何でもやりたいと思っている。それが管理者の逆鱗に触れてアカウント停止にされるのならばそれも致し方ない。ただ、管理者はアカウント停止の強硬手段をとる前に甘い設定を見直すべきだったのではないだろうか。
cgiをサーバ上で動かす前にローカルでチェックする。このチェックが意味を持ってくるのはサーバ上の環境とローカルの環境が完全に同一の場合だ。PurePerlでスクリプトを書いている場合はそれほど気にならないかもしれないが、モジュールを使い始めるとそうもいえない。まず、レンタルサーバ側が導入済みモジュールのバージョンを教えてくれないし、モジュールの中にはバージョン自体を定義していないものもある。つまり、ローカル環境とサーバ環境を同一にするための資料が不足していることが多く、現実問題としてローカルにサーバと完全に同一の環境を構築することはかなりハードルが高い。このハードルを越えれるようなスキルを持ち合わせているようなユーザはそもそもアカウント停止になるような負荷をかけたりはしないだろう。結局、サーバの管理者は間違えてサーバにとってあまりうれしくないcgiをアップロードしてしまうようなユーザの行動を抑止するのに十分なだけの資料を提供していないのではないかと思う。
は言われながらもついついやってしまう。でもさぁ最近頓に思うんだけど、どうして規約には共有サーバ上で未テストのcgiを走らせることを禁止しておきながら、共有サーバ上にある自分のファイルを編集できる管理ページを作るんだろうね。無料ホームページスペースの新しいサービスとしてファイルマネージャとかファイルエディタとか追加されることはそれ自体が規約と逆行しているんじゃないだろうかと思うわけ。
世にあるさまざまな無料ホームページスペースは、そんなサービスを提供している。ということはサーバ上でcgiの編集を許可しているということなんじゃないだろうか。いや僕はあまりこうゆうサービスを使わないから、ファイル編集がどのようなファイルにだけ適応可能なのかは知らないんだけど。つまりもしかしたら、ファイルエディタが編集できるのは拡張子がhtmlのファイルだけとか決まっているのかもしれないけどさ。まぁファイルは内容を単純に送信するだけならサーバに大きな負担をかけるものでないということは認めるけどさ。
上で述べたような無料共有サーバの一つのサービスとして供給されているファイルエディタとかファイルマネージャがクライアントとやり取りするときどんなプロトコルを使っているのかはよく知らないけど、全てのサービスがセキュアな通信手段を使用しているわけではないと思う。多分、どっちにしたって公開される内容のファイルを編集するのに、非公開を前提としたセキュアな通信手段は必要無いと思ったんだろうな。こんな観点からファイルエディタの機能を推測してみると、編集できるのは内容を公開されることが前提となっているhtmlファイルだけかもしれない。cgiはファイルの内容自体がクライアントに提供されるのではなくて走らせた結果が提供されるわけだからね。
でもさぁやっぱり共有サーバの管理者はそれなりにskilfullな人間であってほしいと思うわけ。せっかくサービスの一環としてエディタやマネージャを供給してくれているなら、機能制限を設けてしまうのはもったいないと思う。自作のcgiプログラムを自分のサーバで動作確認したからといって実際にアップロードしたら上手く動作しなかったなんてことはよくあることだと思うな。cgiのエラー状況を教えてくれるくらいの親切な管理人であって欲しいよ。
たとえ悪意あるプログラムがサーバ上で動いたとしても暗躍する前に、機能排除できるようなスキルを持っていて欲しい。高負荷cgiプログラムの引きは時間制限を設けることで一応の成功を見ているわけだし、別サーバとの通信もサーバ設定の書き換えで上手くできているんだから、もう一声欲しいところだよ。セキュアなプロトコルを導入して欲しいな。
たとえ無料共有サーバであったとしても、SSHでも導入してtelnetから編集できるようにしてもらいたいもんだな。有料ならばtelnet接続がSSH化されていないのは問題ありだよ。それに、サーバ上で走らせたCGIがエラーや管理者の予期しない動作をするようなものだったらこれを自力で排除もしくは禁止できるだけのskilfullな管理者であってほしいな。そうでなかったらCGIなんて動作確認が面倒なだけのものでしかないと思う。
直接編集ということを考えるとこれらの選択肢も考えておかねばならないだろう。どちらもfuseを用いてhttpやftpのディレクトリをマウントしてローカルと同様に使えるようにしている。httpfsはそのプロトコル上の制約なのか読み込み専用のようだ、ftpfsは読み書きの両方が可能なようだ。編集という観点かれすれば書き込みが出来ないhttpfsは除くとしてもftpfsは魅力的な選択肢といえる。可能であればftpfsがもっとも良い選択肢だと思われる。これらの方法の問題点はマウントしなければ使えないという点だ。常にマウント可能、つまりftpfsの導入されたマシンがある、かどうかわからないのならftpfsという選択肢も消えてしまう。結局のところ編集用のcgiをつくっておいてブラウザ経由で編集するのが汎用性という観点からすればベストな回答なのかもしれない。
同じことを考える人はやはりいるわけで。CGI.pmでcssが限定的サポートなのでcss出力はどーすんだ、と思っていたらやっぱりあった。
