Linuxでユーザーが何かをマウントする前に、各マウントに対してroot / sudoの使用/特別な承認を受けなければならないのはなぜですか？ユーザーが何かをインストールできるようにするかどうかは、ソースボリューム/ネットワーク共有とマウントポイントへのアクセスに基づいて決定する必要があるようです。非ルートユーザーインストールのいくつかの用途は、ファイルシステムイメージをユーザー所有の方向にマウントし、ネットワーク共有をユーザー所有ディレクトリにマウントすることです。ユーザーがインストール方程式の両面を制御できる場合は素晴らしいと思います。
アクセス制限の説明：
ユーザーが属するマウントポイントにユーザーがアクセスできるすべてのものをインストールできる必要があると思います。
たとえば、マイコンピュータでは、/ dev / sda1はユーザーのルートと特権を持つグループディスクによって所有されていますbrw-rw----。したがって、root以外のユーザーは/ dev / sda1を台無しにすることはできず、明らかにmountはそれらをマウントすることを許可しないでください。ただし、ユーザーが/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つの方法は、オペレーティングシステムがすべてのファイルをインストールを実行しているユーザーに属するものとして扱うことです。しかし、単純な読み取り/書き込み/実行の場合、これがなぜ問題になるのかわかりません。
ユースケース：
私はLabsにアカウントを持ち、家のスペース制限は8GBです。これは小さくてとても面倒です。私のプライベートサーバーからnfsボリュームをマウントして、基本的に私が持っているスペースを増やしたいと思います。しかし、Linuxはこれを許可しないため、8GBの制限を超えないようにファイルを前後にscp'ingする必要がありました。
答え1
これは歴史的な制限とセキュリティの制限です。
歴史的に、ほとんどのドライブは取り外しできませんでした。したがって、正当な物理アクセス権を持ち、rootアカウントにアクセスできるユーザーにインストールを制限することは合理的です。 fstabエントリを使用すると、管理者はリムーバブルドライブのマウントを他のユーザーに委任できます。
セキュリティの観点から見ると、すべてのユーザーがブロックデバイスまたはファイルシステムイメージを任意の場所にマウントできるようにするには、3つの主な問題があります。
- 所有していない場所にインストールすると、その場所のファイルが非表示になります。たとえば、既知のルートパスワードを含むファイル
/etcに必要なファイルシステムをマウントします。/etc/shadowこの問題は、ユーザーが自分の所有するディレクトリにのみファイルシステムをマウントできるようにすることで解決できます。 - ファイルシステムドライバは、誤った形式のファイルシステムに対して徹底的にテストされないことがよくあります。欠陥のあるファイルシステムドライバが原因で、誤った形式のファイルシステムを提供しているユーザーがカーネルにコードを挿入する可能性があります。
- ファイルシステムをマウントすると、マウンタは作成権限を持たないファイルを表示できます。 Setuid実行可能ファイルとデバイスファイルが最も明確な例であり、暗黙的に含まれており、オプションで修正されまし
nosuidたnodev。これまでは。しかし、より一般的には、他のユーザーが所有するファイルを生成できることは問題になります。ファイルの内容がインストーラではなく、その所有者と見なされる可能性があります。ルートから別のファイルシステムに属性を保存する一時コピーをコピーすると、宣言されていますが、関連する所有者ではなく、所有者がファイルを所有します。一部のプログラムでは、ファイルが特定のユーザーに属していることを確認して、ファイルの使用要求が合法であることを確認しますが、これは安全ではありません（プログラムはアクセスパスのディレクトリがそのユーザーに属していることを確認する必要があります。許可されている場合、このディレクトリはマウントされます。ブランチでないこと（rootまたは必須ユーザーがマウントを作成していない場合）も確認する必要があります。user/etc/fstabusermount
実用的な目的で、次のようにルートなしでファイルシステムをマウントできるようになりました。ヒューズ。 FUSEドライバはインストールユーザーとして実行されるため、カーネルコードのバグを悪用して権限が上昇するリスクはありません。 FUSEファイルシステムは、ユーザーが作成権限を持つファイルのみを公開できるため、上記の最後の問題は解決されます。
答え2
ユーザーがブロックデバイスに直接書き込みアクセス権を持っている場合そしてブロックデバイスをマウントした後、ブロックデバイスにsuid実行可能ファイルを作成し、マウントした後にファイルを実行することで、システムへのrootアクセス権を取得できます。これがインストールが通常ルートに制限される理由です。
ルートは通常のユーザーが特定の制限に従ってマウントすることを許可できるようになりましたが、ユーザーがブロックデバイスへの書き込みアクセス権を持っている場合は、同様の問題を持つsuidとdevnodeに対してマウントが許可されていないことを確認する必要があります（ユーザーは、次のことができます）。手動で devnode を作成し、書き込みアクセス権を持たない重要なデバイスへの書き込みアクセス権を付与します。
答え3
必ずしもスーパー権限が必要なわけではありません。 ~から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.
答え4
注：最新のカーネルには「名前空間」サポートがあります。一般ユーザーは、名前空間を作成し、名前空間 root 内でファイルシステムをマウントするなどの興味深い操作を実行できます。
ただし、「実際の」スーパーユーザー権限は付与されません。すでに許可されている操作のみを実行できます（つまり、既に読み取り可能なデバイスのみをインストールできます）。
バラよりネームスペース操作、パート1：ネームスペースの概要、セクション 4.