Home / server / Questions / 282725
Accepted
nicktacular
Asked: 2011-06-22 09:47:17 +0800 CST

Permission denied to remount tmp for exec

  • 772

I'm running Fedora Linux on MediaTemple using their (ve) virtual Linux box. Pretty much a clean install (Linux ************ 2.6.18-028stab089.1 #1 SMP Thu Apr 14 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux).

I'm trying to do some Pear installs and need /tmp to be remounted with exec option. No problem, right? So I'm running as root and I just go for it:

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

Well, this is rather unexpected. MediaTemple support doesn't provide any assistance with this--it's not in the SLA. Given that this is a pretty vanilla setup, perhaps someone out there has an idea what's wrong here?

EDIT:

Here's some additional information. Running mount shows this:
[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 ~]#

The contents of /etc/fstab is:

none /dev/pts devpts rw 0 0

Next I tried adding this line to /etc/fstab:

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

Then running mount /tmp results in:

mount: unknown filesystem type 'simfs'

I'm a little confused as to how simfs is listed when you run mount, but when you add it to /etc/fstab it isn't recognized. Nonetheless, this doesn't seem to solve my issue, so I'm still stuck. Any ideas?

UPDATE 6/25/11

@jamiers has found a workaround that MediaTemple posted (see below). However, I'm now wondering about the more fundamental aspect of this problem. Why is it that you can't remount tmp with different options in a virtual environment? From what I can tell, there's nothing inherently restrictive in a virtual environment that would prevent you from doing something like that. Does anyone have an idea why this is the case?

linux mount virtual-machines exec virtuozzo

4 Answers

  1. Best Answer

    I have had the same trouble while trying to install PHP APC. I followed the instructions at the bottom of this guide: https://kb.mediatemple.net/questions/1987/Noexec+and+%7B47%7Dtmp+Troubleshooting#ve about creating a chrooted environment.

    Hope this helps!

    • 3

  2. Keep in mind that you're running MediaTemple's kernel (and you can't change this). It can allow or deny whatever it wants. You might need the source to their kernel to really understand it. Maybe it's a limitation of the simfs filesystem?

    • 0

  3. In order to mount tmp without noexec you need to remount it from Hardware node.

    For more details refer the following documentation.

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

    • 0

  4. Preamble

    since i can't comment, ill leave an answer. people really need to do their research about openVZ (among other technologies..) before posting...

    i realize that this was a question from a few years ago, but I intend to disambiguate the lies about OpenVZ/Virtuozzo and disinformation about operating system virtualization still propagated today

    OpenVZ

    openVZ is a great piece of technology, that can be used for a plethora of uses. there is many uses for operating system level virtualization, and many people fall into the category of needing this level of simulation...

    its like a Chroot on Steroids, but with the ability to restrict processes tables and separate hardware utilization, in turn allowing for fluent operating systems inside of operating systems: but with a heightened layer of additional security and privacy or isolation while still allowing root access.

    unfortunately, the same lies are spread around about the Chroot function... every one will tell you to use virtualization, and that its not a security feature. most times, this is entirely not true, the insecurity accusations are entirely false, as Chroot is directly integrated into a variety of popular software, usually as a potent security and isolation feature (when used correctly)

    an important note is that not every admin has the level of knowledge needed to secure all the necessary kernel parameters on a dedicated server or under full system virtualization.

    this means that deploying OpenVZ means that your customers will have much less attack surface to try and cover and secure before deploying their applications. a good host will do a good job securing these parameters, and it in turn, this is better for not only everybody on the Node, or in the data-center, but for the internet as a whole...

    Why not Change?

    "considering changing", as Michael Hampton suggests, to full system virtualization, because of "little unknown issues" is not not only overkill be entirely unnecessary. this is the sign of one not fully understanding the intended purpose. full system simulation includes everything, such as the bios and hardware interrupts,

    this means you have less over-head when using OpenVZ, and therefore, in direct correlation to what the evidence concludes (i.e benchmarks), that this will typically result in a faster virtual machine, especially for someone with a lesser level of understanding about *nix, and not to mention higher levels of security.. (to assume that every user with a virtual machine understands kernel security and custom patching is incredulous)

    converting to a new technology is always going to be complicated, and emerging technologies in the open source world are ALWAYS going to take time to be perfected.

    I'm now wondering about the more fundamental aspect of this problem. Why is it that you can't remount tmp with different options in a virtual environment?

    So whats the Issue?

    with that said, and to answer your question , on most modern OpenVZ Kernels these days, the issue is that the kernels pluggable modules appear to be "missing", especially to commands which directly depend on them. but they are still there.

    the explanation is simple, in that openVZ simulated the operating system, and not the kernel. giving guest access to hardware related settings would be insecure. you do not get direct access to hardware, devices, or file systems.

    this may sound cumbersome, but is not (once your get the hang of it), and the trade off between security for new users and experienced users having to understand how to work-around (which an experienced user should know how to do anyways), is sincerely a modest one. on a truly secure dedicated machine or KVM, you would want to implement many of the kernel layer securities existing in a container anyways

    finally, simfs is a simulated file system device for use with openVZ, and is not recognized by the mount file-system command (AFAIK).

    And how do I Fix this?

    not sure if this is the case for you, but it should be resolvable in most newer kernel versions simply be issuing

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

    and in the kernel version one of my host nodes use, i simply dropped the /dev/simfs inside fstab, and mount -a works as expected...

    example: none /tmp simfs defaults,exec 0 0

    I hope this helps somebody.

    • -1