【chroot】 なぜFTPでレンタルサーバーにアクセスしても、他のアカウントのファイルが見れないか?

「共用型のレンタルサーバー」を利用していて、このような疑問を持ったことはありますでしょうか?

  • なぜ他人のディレクトリが見れないのか?
  • なぜ他人のデータが見れないのか?
  • 自分のデータは他人に見られていないのか?

という疑問に対して解説します。

 

下記の記事は具体的に chroot を使って DNS サーバーを構築しています。

 

【CentOS7】 DNSサーバーの構築手順(bind-chroot、bind9.9.4)

 

 

共用型レンタルサーバーなのになぜ他人のデータが見れないのか?

タマちゃん
共用型だからみんなが使っているんだよね?でも他の人のデータは見れないよね?
山ちゃん
見れないように設定しているんだよ

 

 

レンタルサーバーには「共用型」と「専用型」がある

レンタルサーバーには「共用型」「専用型」があります。

  • 共用型のレンタルサーバ → 複数の人に1台のサーバを貸し出すサービス
  • 専用型のレンタルサーバー → 一人に1台のサーバーを貸し出すサービス

 

共用サーバーの場合

 

 

 

専用サーバーの場合

 

メリットデメリット
共用型レンタルサーバー価格が安いできることが限定的
他人の影響を受ける
専用型レンタルサーバーハイスペック
他人の影響を受けない
価格が高い

レンタルサーバーに使える予算がたくさんあれば専用サーバーを借りて自分の好きなようにカスタマイズできます。

しかしカスタマイズよりも安く使いたいなら共用型のレンタルサーバーを利用します。

ただ、正直言って高い料金を払って専用型のレンタルサーバーを借りたところでメリットはあるかと言うと、そんなにはないと思います。

メリットがある場合としては

  • サーバー周りで専門的なスキルがある(最低限レンタルサーバー会社のインフラ系エンジニアと同等レベルもしくはそれ以上)
  • Webアプリを開発しているが、特定の環境でしか動かない(15年前のJavaのバージョンでしか動かないとか・・・でもVPSでも可能か?AWSだと難しい)
  • 膨大なアクセスが見込め、取りこぼしがないようにしたい(共用型レンタルサーバーだと他人の影響を受けるため)

でしょうか。

 

手厚いサポートなら「共用型」でも受けられますし、新しいWebアプリを開発したい場合も「仮想(VPS)」や「クラウド(AWS)」で開発した方がコストを抑えることができると思います。

わざわざ高い料金を払ってでも「専用型レンタルサーバー」にしなければいけない理由はそんなにないです。

共用型のレンタルサーバーはいろんな人が共用しています。

 

たとえばレンタルサーバー会社によって環境が違いますが、「共用型レンタルサーバー」でも

  • 他人のディレクトリが見えるがアクセスできないパターン
  • そもそも自分のディレクトリしか見えないパターン

があります。

 

 

他人のディレクトリが見れるがアクセスできないパターン

これは単純に「アクセス制限」しているからです。

だから見えるけどアクセスはできません。

アカウントがあるのでログインができます。

そしてディレクトリも移動できます。

しかしアクセス制限がされているので、見えるけどアクセスはできません。

ただ、この形式は私は好きではないですね。

というもの、たいていアカウント名でディレクトリを作っているのでセキュリティ的にパスワードがクラッキングされる危険性も高いと思うからです。

そもそもアカウント名も知らなければ、もっとリスクは下がるはずですから。

しかもこの形式でパスワードが「password」とか「testtest」なんて設定していたとしたら怖いですよね。。

 

 

 

そもそも自分のディレクトリしか見えないパターン

次が「そもそも自分のディレクトリしか見えないパターン」です。

ちなみにエックスサーバーの共用型レンタルサーバーの場合は自分のディレクトリしか見えないパターンです。

共用型レンタルサーバーということは複数の人で1台のサーバを使うことになるので、自分が保存したデータと同じサーバーで、他の誰かもデータを保存していることになります。

ということは、設定次第では「他人のディレクトリにアクセスできてデータを読めてしまう」こともあれば「他人からデータを読まれてしまう」可能性もあります。

しかし現状、そんなレンタルサーバーはありませんので安心してください。

では、なぜ他人のデータが見れないのでしょうか?

 

 

chrootで規制している

「FFFTP」とか「WinSCP」などでFTPアカウントで接続したり、sshでレンタルサーバーにログインして利用したりしていると思いますが、「chroot」で他人のディレクトリにアクセスできないように規制されています。

 

 

そもそも「chroot」とは何か?

chroot は「change root」の略です。

特定のプロセスと、その子プロセスに対して「ルートディレクトリを設定」することができます。

通常、ルートディレクトリは「/」で表現されるトップディレクトリになりますが、「chroot」コマンドで設定することより、例えば apache プロセスのルートディレクトリを「/var/chroot/apache」など任意のディレクトリに変更することができます。

要は root(ルートディレクトリ)を変更するコマンドとも言えます。

 

例えば、レンタルサーバーは大体「Linux」で構築されていますが、Linuxのディレクトリ構造はこのようなツリー構造になっています。

/(root)ディレクトリの直下には「/home」や「/var」といったディレクトリが配置されています。

しかし「chroot」で下図のように「/home/yama」ディレクトリをヤマちゃんにとっての「/(root)」ディレクトリに設定して、それ以上、上のディレクトリには行けないようにしています。

また、「見せない」ようにもしています。

アクセス制限をしているのではなく、「閉じ込めている」イメージです。

だから「root監獄」とも言われます。

 

 

man 2 chrootの結果

manページは別に読まなくてもいいんですが、manページを読むと新しい発見というか、何かしら気が付くことがあります。

# man 2 chroot | col -b
CHROOT(2)                   Linux Programmer’s Manual                  CHROOT(2)

NAME
       chroot – change root directory
   chroot – ルートディレクトリを変更する

SYNOPSIS
       #include <unistd.h>

       int chroot(const char *path);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       chroot():
           Since glibc 2.2.2:
               _BSD_SOURCE ||
                   (_XOPEN_SOURCE >= 500 ||
                       _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
                   !(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600)
           Before glibc 2.2.2: none

DESCRIPTION
       chroot() changes the root directory of the calling process to that specified in path.  
    chroot() は、呼び出したプロセスのルートディレクトリをpathで指定されたものに変更します。
       This directory will be used for pathnames  beginning  with /.   
    このディレクトリは、/ で始まるパス名に使用されます。
       The  root  directory  is  inherited  by  all children of the calling process.
    ルートディレクトリは、呼び出し元プロセスのすべての子によって継承されます。

       Only a privileged process (Linux: one with the CAP_SYS_CHROOT capability) may call chroot().
       特権プロセス(Linux:CAP_SYS_CHROOT機能を持つプロセス)だけが chroot() を呼び出すことができます。

       This  call  changes  an ingredient in the pathname resolution process and does nothing else.
       この呼び出しは、パス名解決プロセスの要素を変更し、それ以外は何も行いません。

       This call does not change the current working directory,  so  that  after the  call  ‘.’ can be outside the tree rooted at ‘/’.
        この呼び出しは現在の作業ディレクトリを変更しないので、呼び出しの後に ‘。’ ‘/’を基点とするツリーの外側にある可能性があります。
       In particular, the superuser can escape from a “chroot jail” by doing:
       特に、スーパーユーザーは以下を行うことによって “chroot jail”から脱出することができます:

           mkdir foo; chroot foo; cd ..

       This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.
       この呼び出しは開いているファイルディスクリプタを閉じず、そのようなファイルディスクリプタは chroot ツリーの外側にあるファイルにアクセスすることができます。

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and errno is set appropriately.
       成功するとゼロが返されます。エラーの場合、-1 が返され、errno が適切に設定されます。

ERRORS
       Depending on the file system, other errors can  be  returned.   
       ファイルシステムによっては、他のエラーが返されることがあります。
       The  more general errors are listed below:
       より一般的なエラーは次のとおりです。

       EACCES Search  permission  is  denied  on a component of the path prefix.
       EACCES パスの接頭辞の構成要素で検索許可が拒否されました。
              (See also path_resolution(7).)
              (path_resolution(7)も参照してください)。

       EFAULT path points outside your accessible address space.
       EFAULTパスはアクセス可能なアドレス空間外を指します。

       EIO    An I/O error occurred.
       EIO  I/Oエラーが発生しました。

       ELOOP  Too many symbolic links were encountered in resolving path.
       ELOOP 解決パスにシンボリックリンクが多すぎます。

       ENAMETOOLONG
              path is too long.
              パスが長すぎます。

       ENOENT The file does not exist.
       ENOENT ファイルが存在しません。

       ENOMEM Insufficient kernel memory was available.
       ENOMEM 十分なカーネルメモリが利用できなかった。

       ENOTDIR
              A component of path is not a directory.
              パスのコンポーネントはディレクトリではありません。

       EPERM  The caller has insufficient privilege.
       EPERM 呼び出し側の権限が不十分です。

CONFORMING TO
       SVr4, 4.4BSD, SUSv2 (marked  LEGACY).   This  function  is  not  part  of POSIX.1-2001.

NOTES
       A child process created via fork(2) inherits its parent’s root directory.
       fork(2)で作成された子プロセスは、その親のルートディレクトリを継承します。
       The root directory is left unchanged by execve(2).
       ルートディレクトリはexecve(2)によって変更されません。

       FreeBSD has a stronger jail() system call.
       FreeBSD はもっと強力な jail() システムコールを持っています。

SEE ALSO
       chdir(2), path_resolution(7)

COLOPHON
       This page is part of release 3.53 of  the  Linux  man-pages  project.   
       このページは、Linux man-pagesプロジェクトのリリース3.53に含まれています。
       A description  of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/.
       プロジェクトの説明とバグの報告に関する情報は、http://www.kernel.org/doc/man-pages/にあります。

Linux                              2010-09-20                          CHROOT(2)

 

 

結論

いろいろな理由から他人のディレクトリが見えるレンタルサーバーより、見れないレンタルサーバーの方がいいと思いました。

最近エックスサーバーを使っていて、値段の割には「かゆいところに手が届く」ようなサービスを提供しているのでお勧めしています。

月額900円(税抜)から、高速・多機能・高安定レンタルサーバー『エックスサーバー』 

 

 

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメント一覧 (1件)

コメントする

AlphaOmega Captcha Medica  –  What Do You See?
     
 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください