权限被拒绝重新挂载 tmp 以供执行

权限被拒绝重新挂载 tmp 以供执行

我在 MediaTemple 上使用他们的 (ve) 虚拟 Linux 盒运行 Fedora Linux。几乎是全新安装 (Linux ************ 2.6.18-028stab089.1 #1 SMP Thu Apr 14 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux)。

我正在尝试进行一些 Pear 安装,需要/tmp使用exec选项重新安装。没问题吧?所以我以以下方式运行root

[root@host ~]# mount -o remount,exec /tmp
mount: permission denied
[root@host ~]#

嗯,这有点出乎意料。MediaTemple 支持不提供任何帮助——它不在 SLA 中。鉴于这是一个非常普通的设置,也许有人知道这里出了什么问题?

编辑:

以下是一些附加信息。运行结果mount显示:
[root@host ~]# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
/dev/simfs on /tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
/dev/simfs on /var/tmp type simfs (rw,noexec,relatime,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type tmpfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
[root@host ~]#

的内容/etc/fstab为:

none /dev/pts devpts rw 0 0

接下来我尝试将这一行添加到/etc/fstab

/dev/simfs /tmp simfs rw,exec,relatime,usrquota,grpquota 0 0

然后运行mount /tmp结果为:

mount: unknown filesystem type 'simfs'

我有点困惑,为什么simfs运行 mount 时会列出,但添加时却/etc/fstab无法识别。尽管如此,这似乎无法解决我的问题,所以我仍然陷入困境。有什么想法吗?

更新日期:6/25/11

@jamiers找到了 MediaTemple 发布的解决方法(见下文)。但是,我现在想知道这个问题的更根本的方面。为什么在虚拟环境中不能使用不同的选项重新挂载 tmp?据我所知,虚拟环境中没有任何固有的限制会阻止您执行此类操作。有人知道为什么会这样吗?

答案1

尝试安装 PHP APC 时我遇到了同样的问题。我按照本指南底部的说明进行操作:https://kb.mediatemple.net/questions/1987/Noexec+and+%7B47%7Dtmp+Troubleshooting#ve关于创建 chrooted 环境。

希望这可以帮助!

答案2

请记住,您正在运行 MediaTemple 的内核(您无法更改这一点)。它可以允许或拒绝任何它想要的东西。您可能需要他们的内核源代码才能真正理解它。也许这是 simfs 文件系统的限制?

答案3

为了在没有 noexec 的情况下挂载 tmp,您需要从硬件节点重新挂载它。

有关更多详细信息,请参阅以下文档。

http://download.swsoft.com/virtuozzo/virtuozzo4.0/docs/en/lin/VzLinuxUG/18548.htm

答案4

前言

因为我不能发表评论,所以我会留下答案。真的在发布之前需要对 openVZ(以及其他技术)进行研究...

我知道这是几年前的问题,但我打算澄清关于 OpenVZ/Virtuozzo 的谎言以及至今仍在传播的关于操作系统虚拟化的虚假信息

开放VZ

openVZ 是一项伟大的技术,可以用于多种用途。操作系统级虚拟化有很多用途,很多人都需要这种级别的模拟......

它就像是加强版的 Chroot,但具有限制进程表和分离硬件使用的能力,从而允许在操作系统内部实现流畅的操作系统:但具有更高的安全性和隐私性或隔离性同时仍然允许 root 访问。

不幸的是,关于 Chroot 功能的谎言也四处流传……每个人都会告诉你使用虚拟化,而这不是一个安全功能。大多数时候,这完全不是事实,不安全的指控完全是错误的,因为 Chroot 直接集成到各种流行软件中,通常作为强大的安全和隔离功能(使用时正确地

需要注意的是,并非每个管理员都具备在专用服务器或完整系统虚拟化下保护所有必要内核参数所需的知识水平。

这意味着部署 OpenVZ 意味着你的客户在部署之前需要尝试覆盖和保护的攻击面会大大减少他们的应用程序。一个好的主机将很好地保护这些参数,反过来,这不仅对节点或数据中心上的每个人都有好处,而且对整个互联网都有好处……

为什么不改变?

正如迈克尔·汉普顿所建议的,“考虑改变”全系统虚拟化因为“小的未知问题”而进行测试,这不仅是过度的,也是完全没有必要的。这是一个没有完全理解预期目的的标志。完整的系统模拟包括所有内容,例如 BIOS 和硬件中断,

这意味着使用 OpenVZ 时开销更小,因此,与证据(即基准)得出的结论直接相关,这通常会带来更快的虚拟机,特别是对于那些对 *nix 了解程度较低的人来说,更不用说更高级别的安全..(假设每个拥有虚拟机的用户都了解内核安全和自定义补丁是令人难以置信的)

转换一项新技术总是很复杂的,并且开源世界中的新兴技术总是需要时间来完善。

我现在想知道这个问题更根本的方面。为什么在虚拟环境中不能使用不同的选项重新挂载 tmp?

那么问题是什么?

照这样说,并回答你的问题目前,在大多数现代 OpenVZ 内核中,问题在于内核的可插入模块似乎“丢失”,尤其是对于直接依赖于它们的命令而言。但它们是还在那儿

解释很简单,openVZ 模拟的是操作系统,而不是内核。让访客访问硬件相关设置是不安全的。您无法直接访问硬件、设备或文件系统。

这可能听起来很麻烦,但不是(一旦你掌握了窍门),新用户的安全性和有经验的用户必须了解如何解决(有经验的用户无论如何都应该知道如何做)之间的权衡,确实是适度的。在真正安全的专用机器或 KVM 上,你可能希望实现容器中存在的许多内核层安全性无论如何

最后,simfs 是一个模拟文件系统设备 用于 openVZ,并且无法被 mount 文件系统命令识别(据我所知)。

我该如何修复这个问题?

不确定你的情况是否如此,但在大多数较新的内核版本中应该可以解决,只需发出

mount --bind -o defaults,exec /tmp /tmp

在我的一个主机节点使用的内核版本中,我只需将 /dev/simfs 放在 fstab 中,就可以mount -a按预期工作......

例子: none /tmp simfs defaults,exec 0 0

我希望这对某人有帮助。

相关内容