マウントにroot権限が必要なのはなぜですか？
なぜLinuxは、何かをマウントするために、ユーザーがroot/Sudoを使用している/マウントごとに特別に承認されている必要があるのですか？ユーザーが何かをマウントできるようにするかどうかの決定は、ソースボリューム/ネットワーク共有およびマウントポイントへのアクセス権に基づく必要があるようです。非ルートマウントの2つの用途は、ファイルシステムイメージをユーザーが所有する方向にマウントすることと、ネットワーク共有をユーザーが所有するディレクトリにマウントすることです。ユーザーがマウント式の両側を制御できる場合、すべてがクールになるはずです。
アクセス制限の明確化：
私は、ユーザーが所有者であるマウントポイントへのアクセス権をユーザーに付与できるものであれば、何でもマウントできるはずだと感じています。
たとえば、私のコンピューターでは、/ dev/sda1はユーザーrootとグループディスクによって所有されており、権限は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ではそのようなことは許可されていないため、scp処理のファイルが8 GBの制限を超えないようになっています。
これは、歴史的かつセキュリティ上の制限です。
歴史的に、ほとんどのドライブは取り外し可能ではありませんでした。したがって、正当な物理的アクセスを持つ人々にマウントを制限することは理にかなっており、彼らはおそらくrootアカウントにアクセスできるでしょう。 fstabエントリにより、管理者はリムーバブルドライブのマウントを他のユーザーに委任できます。
セキュリティの観点から、任意のユーザーが任意のブロックデバイスまたはファイルシステムイメージを任意の場所にマウントできるようにすることには、3つの大きな問題があります。
- 所有されていない場所にマウントすると、その場所にあるファイルがシャドウイングされます。例：選択したファイルシステムを
/etcにマウントし、/etc/shadowに既知のルートパスワードを含めます。これは、ユーザーが自分が所有するディレクトリにのみファイルシステムをマウントできるようにすることで修正されました。 - ファイルシステムドライバは、多くの場合、不正なファイルシステムで徹底的にテストされていません。バグのあるファイルシステムドライバーを使用すると、ユーザーは不正なファイルシステムを提供して、カーネルにコードを挿入できます。
- ファイルシステムをマウントすると、マウンターは、他の方法では作成する権限を持っていないように見えるファイルを表示させることができます。 Setuid実行可能ファイルとデバイスファイルは、最も明白な例であり、
nosuidおよびnodevオプションによって修正されます。これらのオプションは、userを/etc/fstabに含めることで暗黙指定されます。
これまでのところ、userがrootによって呼び出されない場合は、mountを強制するだけで十分です。しかし、より一般的には、別のユーザーが所有するファイルを作成できることには問題があります。そのファイルのコンテンツは、マウンターではなく、所有者と呼ばれる人物に帰属するリスクがあります。 rootによる別のファイルシステムへのカジュアルな属性保持コピーは、宣言されているが関与していない所有者が所有するファイルを生成します。一部のプログラムは、特定のユーザーがファイルの所有者であることを確認することにより、ファイルの使用要求が正当であることを確認しますが、これは安全ではなくなります（プログラムは、アクセスパス上のディレクトリがそのユーザーが所有していることも確認する必要があります。任意のマウントが許可されている場合は、これらのディレクトリのいずれもが、マウントがルートでも目的のユーザーでも作成されていないマウントポイントでないことを確認する必要があります。
Fuse を使用して、実際にはrootにならずにファイルシステムをマウントすることが可能です。ヒューズドライバーはマウントユーザーとして実行されるため、カーネルコードのバグを悪用することによる特権昇格のリスクはありません。ヒューズファイルシステムは、ユーザーが作成する権限を持つファイルのみを公開できるため、上記の最後の問題が解決されます。
ユーザーがブロックデバイスへの直接書き込みアクセス権を持っている場合、andはそのブロックデバイスをマウントでき、その後、suid実行可能ファイルをブロックデバイスに書き込み、マウントして、そのファイルを実行できます。システムへのrootアクセスを取得します。これが、マウントが通常ルートに制限されている理由です。
これで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.
Kormacや他の人たちは、これはあなたが提示したジレンマではないことを指摘しました。これは、明示的にユーザー特権を付与する対システムの哲学に帰着するようです。これにより、すべてのユーザーがファイルシステムをマウントする不変の権利を持ちます。
Gillesは、ファイルシステムのマウントに関連するセキュリティ問題のいくつかに対処しています。私は、これに関連する潜在的な技術的な問題についてのプロローグされた接線の議論を遡って回避します（コメントを参照）が、信頼できないユーザーがハードドライブをマウントする不変の権利を持たないのは当然だと思います。
仮想ファイルシステムとリモートファイルシステム（または仮想ファイルシステム経由のリモートファイルシステム、Fuse la）に関する問題はそれほど重要ではありませんが、これはセキュリティの問題を解決しません（Fuseは可能性がありますが、問題は確実に解決します）。また、そのようなファイルシステムのデータは、ほとんどの場合、デバイスをマウントしなくても、ファイル転送またはマウントせずにイメージから抽出するツールを使用してアクセスできるため、何かをマウントできないシステムでは、イメージファイルに奇妙に配置したデータへのアクセス、または（よりわかりやすく）リモートシステムから取得したいデータへのアクセスに関して、乗り越えられない問題ではありません。これが当てはまらない状況がある場合は、尋ねる価値があります。
正確に何をしようとしているのですか？
どこでしようとしていますか？
システムの管理が公正である場合、＃2は＃1が不可能な理由を説明しています。システムの管理が公平でない場合、それは政治です。 「私のsys管理者は公平ではない」という問題の解決策は、OSを再設計しないことで、どこでもsys管理者がユーザーを制限できないようにすることです。
このシステムを使用すると、スーパーユーザーは明示的に、または省略して（「Fuseは提供しません」など）、アクティビティを制限できます。特権は、これを実現するための1つのメカニズムです。 「これを行う必要はありません」と言われるのは良いことではないかもしれませんが、それが本当なら... que sera ...これを行う必要はありません。 FTPなどを使用します。それが真実でない場合は、責任を負うべきです。
参考：最新のカーネルは「名前空間」をサポートしています。通常のユーザーは名前空間を作成し、その名前空間内でrootになり、マウントファイルシステムのような楽しいことを行うことができます。
ただし、「実際の」スーパーユーザー権限は付与されません-すでに許可されていることのみを実行できます（つまり、すでに読み取ることができるデバイスのみをマウントできます）。
運用中の名前空間、パート1：名前空間の概要 、セクション4を参照してください。
マウントしようとするファイルシステム上のデータは、サーバーのセキュリティを危険にさらしたり、クラッシュしたりする可能性があるためです（意図的にそのように構築された場合）。
GNOMEでは、gvfsはリモートファイルシステム（ftpまたはssh）をマウントするためのrootを必要としません。また、gnome-mountは外部ストレージ（usbドライブ、CD/DVDなど）をマウントするためのrootを必要としません。
ほとんどのシステムは、おそらく一部のリモートマウントのためだけにGNOME全体を必要としないでしょう。その場合は、 lufs 、 sshfs または ftpfs を使用できます。
gvfs、lufs、sshfs、およびftpfsはFuseを使用して、root以外のユーザーが仮想ファイルシステムをマウントできるようにします。マウントとは異なり、-o user、Fuseでは、sysadminが特定のマウントを調整する必要はありません。マウントディレクトリと、ファイルシステムを構築するために必要なリソースに対する特権がある限り、Fuseマウントを作成できます。
マウントにroot権限が必要なのはなぜですか？
mountは主に/元々ローカルファイルシステムを対象としているため、ほとんどの場合ハードウェアが関与します。