マウントにルート権限が必要なのはなぜですか？

Linuxでは、何かをマウントするために、rootであるか、sudoを使用しているか、マウントごとに特別に許可されている必要があるのですか？ユーザーが何かをマウントできるようにするかどうかは、ソースボリューム/ネットワーク共有およびマウントポイントへのアクセス権に基づいて決定する必要があるようです。非ルートマウントのいくつかの用途は、ファイルシステムイメージをユーザーが所有する方向にマウントすることと、ネットワーク共有をユーザーが所有するディレクトリにマウントすることです。ユーザーがマウント方程式の両側を制御できれば、すべてがクールになるはずです。

アクセス制限の明確化：

そうでなければ、ユーザーが所有者であるマウントポイントにアクセスできるユーザーなら何でもマウントできるはずです。

たとえば、私のコンピューターでは、/ dev / sda1はユーザーrootとグループディスクdiskに所有権がありbrw-rw----ます。したがって、非rootユーザーは/ dev / sda1を台無しにすることはできず、明らかにマウントを許可しないでください。ただし、ユーザーが/home/my_user/my_imagefile.imgとマウントポイント/ home / my_user / my_image /を所有している場合、次の方法でそのマウントポイントにそのイメージファイルをマウントできないのはなぜですか。

mount /home/my_user/my_imagefile.img /home/my_user/my_image/ -o loop

kormacが指摘したように、suidの問題があります。したがって、suidが問題になるのを防ぐために、いくつかの制限を追加する必要があります。おそらくこれを行う1つの方法は、OSがすべてのファイルをマウントを行ったユーザーに属するものとして扱うようにすることです。ただし、単純な読み取り/書き込み/実行の場合、これが問題になる理由はわかりません。

使用事例：

自宅のスペースが8GBに制限されているラボにアカウントを持っています。これは小さく、非常に迷惑です。パーソナルサーバーからnfsボリュームをマウントして、必要なスペースを本質的に増やしたいと思います。ただし、Linuxではそのようなことが許可されていないため、8 GBの制限を超えないようにファイルをscpすることで行き詰まってしまいます。

これは、歴史的およびセキュリティ上の制限です。

歴史的に、ほとんどのドライブはリムーバブルではありませんでした。そのため、正当な物理的アクセスを持つ人々にマウントを制限することは理にかなっており、彼らはおそらくルートアカウントへのアクセスを持っているでしょう。管理者は、fstabエントリを使用して、リムーバブルドライブのマウントを他のユーザーに委任できます。

セキュリティの観点から、任意のユーザーが任意のブロックデバイスまたはファイルシステムイメージを任意の場所にマウントできるようにすることには、3つの大きな問題があります。

• 所有されていない場所にマウントすると、その場所のファイルがシャドウされます。例：上の任意のファイルシステムをマウント/etcして、/etc/shadowあなたが知っているrootのパスワードを含みます。この問題は、ユーザーが所有するディレクトリにのみファイルシステムをマウントできるようにすることで修正されました。
• ファイルシステムドライバは、多くの場合、不正な形式のファイルシステムでは十分にテストされていません。バグのあるファイルシステムドライバーは、不正な形式のファイルシステムを提供するユーザーがカーネルにコードを挿入できるようにする可能性があります。
• ファイルシステムをマウントすると、マウンターは、他の方法では作成する許可を持っていないファイルを表示することができます。Setuid実行可能ファイルとデバイスファイルは最も明白な例であり、これらはin を持つことで暗示されるnosuidおよびnodevオプションによって修正されます。 これまでのところ、user/etc/fstab
usermountルートによって呼び出されないだけで十分です。しかし、より一般的には、別のユーザーが所有するファイルを作成できるかどうかには問題があります。そのファイルのコンテンツは、マウンターではなく、所有者とみなされるリスクがあります。ルートによる別のファイルシステムへのカジュアルな属性保持コピーは、宣言されているが関与していない所有者が所有するファイルを生成します。一部のプログラムは、ファイルが特定のユーザーによって所有されていることを確認することにより、ファイルを使用する要求が正当であることを確認します。任意のマウントが許可されている場合、これらのディレクトリのいずれも、ルートでも目的のユーザーでもないマウントが作成されたマウントポイントではないことを確認する必要があります。

実際には、最近ではFUSEを使用して、rootにならずにファイルシステムをマウントすることが可能です。FUSEドライバーはマウントするユーザーとして実行されるため、カーネルコードのバグを悪用することによる特権昇格のリスクはありません。FUSEファイルシステムは、ユーザーが作成する権限を持つファイルのみを公開できます。これにより、上記の最後の問題が解決されます。

ユーザは、ブロック・デバイスへの直接書き込みアクセスを有し、場合及びそのブロックデバイスをマウントすることができ、それらは、ブロック・デバイスへのSUID実行ファイルを書き込むマウント、それ、そのファイルを実行し、したがって、利得システムへのルートアクセスをすることができます。これが、マウントが通常ルートに制限される理由です。

これで、rootは通常のユーザーが特定の制限付きでマウントできるようになりましたが、ユーザーがブロックデバイスへの書き込みアクセス権を持っている場合、マウントがsuidを許可していないこと、および同様の問題があるdevnodeも確認する必要があります（ユーザーは作成できます）書き込みアクセスを許可しない重要なデバイスへの書き込みアクセスを許可するDevnode）。

常にスーパー特権が必要なわけではありません。からman mount

   The non-superuser mounts.
          Normally,  only  the  superuser can mount filesystems.  However,
          when fstab contains the user option on a line, anybody can mount
          the corresponding system.

          Thus, given a line

                 /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide

          any  user  can  mount  the iso9660 filesystem found on his CDROM
          using the command

                 mount /dev/cdrom

          or

                 mount /cd

          For more details, see fstab(5).  Only the user  that  mounted  a
          filesystem  can unmount it again.  If any user should be able to
          unmount, then use users instead of user in the fstab line.   The
          owner option is similar to the user option, with the restriction
          that the user must be the owner of the special file. This may be
          useful e.g. for /dev/fd if a login script makes the console user
          owner of this device.  The group option  is  similar,  with  the
          restriction  that  the  user  must be member of the group of the
          special file.

コルマックと他の人は、これがあなたがそれを提示するジレンマではないことを示しました。私には、これはすべてのユーザーがファイルシステムをマウントする不変の権利を持つシステムに対して、ユーザー特権を明示的に付与するという哲学に帰着するようです。

Gillesは、ファイルシステムのマウントに関連するセキュリティ問題のいくつかに対処しています。これに関連する潜在的な技術的問題についてのプロローグで接線的な議論をさかのぼって回避します（コメントを参照）が、信頼できないユーザーがハードドライブをマウントする不変の権利を持っていないことは公平だと思います。

仮想ファイルシステムとリモートファイルシステム（または仮想ファイルシステムを介したリモートファイルシステム、la FUSE）に関する問題はそれほど重要ではありませんが、これはセキュリティの問題を解決しません（ただし、FUSEは可能性があり、確かにあなたの問題を解決します）。また、そのようなファイルシステムのデータは、ファイル転送またはマウントせずにイメージから抽出するツールを介して、デバイスをマウントすることなくほとんど常にアクセスできることを考慮することが重要です。画像ファイルに奇妙に配置したデータへのアクセスに関して、または（より理解しやすいように）リモートシステムから取得したいデータへのアクセスに関して、克服できない問題を表すものではありません。これが当てはまらない状況がある場合は、尋ねる価値があるかもしれません：

1. まさに私がやろうとしていることは何ですか？

2. どこでやろうとしていますか？

システムの管理が公正な場合、＃2は＃1があなたにとって不可能な理由を説明します。システムの管理が公正でない場合、それは政治です。「私のシステム管理者は公平ではありません」という問題の解決策は、どこでもシステム管理者がユーザーを制限できないようにOSを再設計しないことです。

このシステムにより、スーパーユーザーは明示的に、または省略して（「FUSEは提供しません」など）アクティビティを制限できます。特権は、これを実現する1つのメカニズムです。「あなたはこれをする必要はない」と言われるのは良いことではないかもしれませんが、それが本当なら...セラ...あなたはこれをする必要はありません。ftpなどを使用します。そうでない場合は、責任者を困らせる必要があります。

参考：最新のカーネルは「名前空間」をサポートしています。通常のユーザーは名前空間を作成し、その名前空間内で、root マウントファイルシステムなどの楽しいものになり 、それを実行できます。

ただし、「本当の」スーパーユーザーのアクセス許可は与えられません-既に許可されていることしかできません（つまり、読み取り可能なデバイスのみをマウントできます）。

http://lwn.net/Articles/531114/ セクション4を参照してください。

マウントしようとしているファイルシステム上のデータは、サーバーのセキュリティを危険にさらしたり、クラッシュしたりする可能性があるためです（意図的に構築された場合）。

GNOMEでは、gvfsはリモートファイルシステム（ftpまたはssh）をマウントするためにrootを必要としません。また、gnome-mountは外部ストレージ（usbドライブ、CD / DVDなど）をマウントするためにrootを必要としません。

ほとんどのシステムはおそらく、あなたが使用することができ、単にいくつかのリモートマウントのために全体のGNOMEを持ってしたいとは思わないでしょうLUFS、sshfsのかftpfsを。

gvfs、lufs、sshfs、およびftpfsはFUSEを使用して、非ルートユーザーが仮想ファイルシステムをマウントできるようにします。また、mountとは異なり-o user、FUSEは特定のマウントを配置するためにsysadminを必要としません。マウントディレクトリと、ファイルシステムの構築に必要なリソースに対する特権を持っている限り、FUSEマウントを作成できます。

マウントにルート権限が必要なのはなぜですか？

なぜならmount、ほとんど/常に元々はローカルファイルシステムを対象としているため、ほとんどの場合、ハードウェアが関係しています。