В разрешении отказано в перемонтировании tmp для exec
Я использую Fedora Linux на MediaTemple, используя их (виртуальную) виртуальную Linux-систему. Практически чистая установка (Linux ************ 2.6.18-028stab089.1 #1 SMP Четверг, 14 апреля 13:46:04 MSD 2011 x86_64 x86_64 x86_64 GNU/Linux).
Я пытаюсь сделать некоторые установки Груша и нужно /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 это не признается. Тем не менее, это, похоже, не решает мою проблему, поэтому я все еще застрял. Есть идеи?
ОБНОВЛЕНИЕ 25/25/11
@jamiers нашел обходной путь, который MediaTemple разместил (см. ниже). Тем не менее, я теперь задаюсь вопросом о более фундаментальном аспекте этой проблемы. Почему вы не можете перемонтировать tmp с различными опциями в виртуальной среде? Из того, что я могу сказать, нет ничего изначально ограничивающего в виртуальной среде, которое помешало бы вам сделать что-то подобное. У кого-нибудь есть идея, почему это так?
4 ответа
У меня была такая же проблема при попытке установить PHP APC. Я следовал инструкциям в нижней части этого руководства: https://kb.mediatemple.net/questions/1987/Noexec+and+%7B47%7Dtmp+Troubleshooting устранение неполадок#ve по созданию среды chroot.
Надеюсь это поможет!
Чтобы смонтировать tmp без noexec, вам необходимо перемонтировать его с узла Hardware.
Для более подробной информации обратитесь к следующей документации.
http://download.swsoft.com/virtuozzo/virtuozzo4.0/docs/en/lin/VzLinuxUG/18548.htm
Имейте в виду, что вы используете ядро MediaTemple (и вы не можете это изменить). Он может разрешить или запретить все, что захочет. Вам может понадобиться исходный код их ядра, чтобы по-настоящему понять это. Может быть, это ограничение файловой системы simfs?
преамбула
так как я не могу комментировать, я оставлю ответ. люди действительно должны сделать свое исследование об openVZ (среди других технологий..) перед публикацией...
Я понимаю, что это был вопрос нескольких лет назад, но я намерен устранить неоднозначность лжи об OpenVZ/Virtuozzo и дезинформации о виртуализации операционной системы, которая до сих пор распространяется сегодня.
OpenVZ
openVZ - это отличная технология, которую можно использовать для самых разных целей. существует много применений для виртуализации на уровне операционной системы, и многие люди попадают в категорию нуждающихся в этом уровне симуляции...
Это похоже на Chroot на стероидах, но с возможностью ограничения таблиц процессов и отдельного использования оборудования, что, в свою очередь, позволяет свободно использовать операционные системы внутри операционных систем: но с повышенным уровнем дополнительной безопасности и конфиденциальности или изоляции, при этом все еще обеспечивая корневой доступ.
к сожалению, та же самая ложь распространяется вокруг функции Chroot... каждый скажет вам использовать виртуализацию, и это не функция безопасности. в большинстве случаев это совершенно не соответствует действительности, обвинения в небезопасности полностью ложны, поскольку Chroot напрямую интегрируется в различные популярные программы, обычно в качестве мощной функции защиты и изоляции (при правильном использовании)
важно отметить, что не каждый администратор обладает уровнем знаний, необходимым для защиты всех необходимых параметров ядра на выделенном сервере или при полной виртуализации системы.
это означает, что развертывание OpenVZ означает, что у ваших клиентов будет гораздо меньше возможностей для атаки, чтобы попытаться их защитить и обезопасить перед развертыванием своих приложений. Хороший хост хорошо справится с защитой этих параметров, и это, в свою очередь, лучше не только для всех на узле или в дата-центре, но и для Интернета в целом...
Почему бы не изменить?
"рассмотреть возможность изменения", как полагает Майкл Хэмптон, для полной виртуализации системы, потому что "малоизвестные проблемы" не только не лишние, но и совершенно ненужные. это признак того, что человек не полностью понимает предназначенную цель. полная симуляция системы включает в себя все, такие как BIOS и аппаратные прерывания,
это означает, что у вас меньше накладных расходов при использовании OpenVZ, и, следовательно, в прямой зависимости от того, что делает вывод (например, тесты), это обычно приводит к более быстрой виртуальной машине, особенно для человека с меньшим уровнем понимания *nix, и не говоря уже о более высоких уровнях безопасности... (предполагать, что каждый пользователь с виртуальной машиной понимает безопасность ядра и нестандартные исправления, просто невероятно)
Переход на новую технологию всегда будет сложным, а новые технологии в мире открытого исходного кода ВСЕГДА будут нуждаться в совершенствовании.
Теперь я задаюсь вопросом о более фундаментальном аспекте этой проблемы. Почему вы не можете перемонтировать tmp с различными опциями в виртуальной среде?
Так в чем же проблема?
С учетом сказанного, и, чтобы ответить на ваш вопрос, в большинстве современных ядер OpenVZ в настоящее время проблема заключается в том, что подключаемые модули ядра "отсутствуют", особенно для команд, которые напрямую зависят от них. но они все еще там.
Объяснение простое, в том, что openVZ моделирует операционную систему, а не ядро. Предоставление гостевого доступа к аппаратным настройкам было бы небезопасным. вы не получаете прямой доступ к оборудованию, устройствам или файловым системам.
это может показаться громоздким, но это не так (как только вы освоитесь с этим), и между компромиссом между безопасностью для новых пользователей и опытных пользователей, которые должны понимать, как обходиться (что опытный пользователь должен знать, как это сделать в любом случае) Искренне скромный. на действительно защищенной выделенной машине или KVM вы захотите внедрить многие ценные бумаги уровня ядра, так или иначе существующие в контейнере
наконец, simfs - это имитируемое устройство файловой системы для использования с openVZ, которое не распознается командой mount file-system (AFAIK).
И как мне это исправить?
не уверен, что это так, но это должно быть разрешено в большинстве новых версий ядра, просто выпуская
mount --bind -o defaults,exec /tmp /tmp
и в версии ядра, которую использует один из моих узлов, я просто удалил /dev/simfs внутри fstab, и mount -a работает как положено...
пример: none /tmp simfs defaults,exec 0 0
Надеюсь, это кому-нибудь поможет.