这是一个非常理论化的问题,在现实世界中没有实际用途。
有没有办法确定安装点可以(不)驻留的位置或位置列表?
据我所知,我的理解充其量是微薄的,你可以指定任何用于安装卷的可访问目录。但你能装进去/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
好消息不过,是你吗能使开发人员用户/巨魔能够在最奇怪的地方安装东西,而不影响文件系统的其余部分。 A文件系统命名空间给一个进程(或一组进程)他们自己的文件系统的想法。就是这样容器是建立在!比如说,如果您安装了podman
(并且您的发行版或您自己制作了适当的条目/etc/subuid
,/etc/subgid
以便您可以运行非特权容器),您的普通用户可以运行类似
podman run -it --rm -v /home/user/data:/boot/fooobar:Z debian:stable
令他们高兴的是,在容器内安装了一个他们可以访问的目录 /boot/foobar,并获得一个 shell 进程来查看该目录,而不是用户的其他进程所看到的。