これは現実の世界ではまったく利用されない非常に理論的な質問です。
マウントポイントが存在できる場所または場所のリストを決定する方法はありますか？
私が知る限り、私の理解はせいぜい貧弱です。どのボリュームマウント用にアクセス可能なディレクトリです。しかし、それを入れることができますか/boot/myvolume？インストールに問題があります/run/shm/myvolume（起動するたびにディレクトリを再作成するとします）？
ボリュームをインストールする人やプログラムが完全なトロールであっても、ボリュームとオペレーティングシステムの意図された機能を破壊することなく、インストールが合理的に持続する可能性がある（または逆に持続しない可能性がある）リストを探しています。
私はどんなLinuxバージョンにも限定しないように努力していますが、これが議論にとって重要である場合は、好みの順序でDebian、Red Hat、Arch、および/またはSUSEに基づいているとします。最も人気のある味だと思います。
答え1
Linuxでは、マウントポイントがどこにでも存在できます。奇妙に見える場所、特にバインドマウントアイテムにアイテムをインストールすることは、特定のプログラムが使用できる環境を作る比較的一般的な方法なので、/boot/myvolumeがまったく特別だとは思わない。代わりに、/boot/EFI はシステムの別個のマウントポイントにすることができます。
ボリュームをインストールする人やプログラムが完全なトロールであっても、ボリュームとオペレーティングシステムの意図された機能を破壊することなく、インストールが合理的に持続する可能性がある（または逆に持続しない可能性がある）リストを探しています。
リストは空です。ファイルシステムの目的は、特定のコンテンツにアクセスするための構造化された方法を提供することです。何もせずに何かを入れることができるディレクトリがある場合は、おそらくそのディレクトリを削除する必要があります。誰も使用しません。
トロールがシステムに何でもインストールする権限を持っている場合、あなたは敗北し、トロールはシステムを所有します。実際、これに対する保護はありません。
むしろ、ユーザーが自分のプロセスを混同する危険を避け、自分のホームディレクトリ（おそらく/run/media/[user]/、）の範囲内で何をしたいのかを考えることは合理的です。/var/run/user/[uid]一般的にこれがポイントです。ユーザーを制限したいのです。どのディレクトリに潜在的に変更アクセス権が必要ですか？とにかく彼らはそのディレクトリを台無しにすることができるので、そこにも物事をインストールできるはずです。悪くならないでしょう。
問題は一般ユーザーとしてできない一般的に物を設置してください。必要な（root）権限で実際に実行されているサービスまたはsetuidプログラム（udisks、systemd-automount、podman ...）を参照し、（要求されたユーザーとして）アクセス可能な場所にのみその項目をインストールすることを確認します。 :
# I'm at home. Can do arbitrary stuff here.
> fallocate -l 1G ~/filesystemimage
> mkfs.xfs ~/filesystemimage
# doesn't let me mount just anywhere, but picks the directory for me
# in a place that has a SELinux context that says, hey, programs like
# udisks can mount there (ls -Z /run/media/marcus: `system_u:object_r:mnt_t`)
# and that is named preeeeetty unambiguously so that any reasonable human or
# software author will not think of relying on any data there unless
# run as the same user
> udisksctl loop-setup -f ~/filesystemimage
# Will let me mount a remote directory in a directory I own:
> mkdir ~/mnt
> sshfs [email protected]:/data ~/mnt && echo Success || echo Faaaail
Success
# … but will straight up refuse to mount where I'm not the owner
# /opt is owned by root, not me
> sshfs [email protected]:/data /opt && echo Success || echo Faaaail
Faaaail
良いニュースしかし、あなたですか？できる開発者ユーザー/トロールがファイルシステムの残りの部分に影響を与えることなく、最も奇妙な場所に物をインストールできるようにします。 ㅏファイルシステムの名前空間プロセス（またはプロセスグループ）に独自のファイルシステムを提供するというアイデアです。それだけです。コンテナそれに基づいて作られました！たとえば、インストールした場合podman（およびディストリビューションまたは自分が権限のないコンテナを実行できる/etc/subuidように適切なエントリを作成した/etc/subgid場合）、一般ユーザーは次のことを実行できます。
podman run -it --rm -v /home/user/data:/boot/fooobar:Z debian:stable
喜んで、/boot/foobarディレクトリはアクセス可能なコンテナ内にマウントされ、他のプロセスが表示するのではなく、そのディレクトリを表示できるシェルプロセスを取得します。