Назад | Перейти на главную страницу

Факторы производительности и безопасности символических ссылок

Я думаю о развертывании очень урезанной версии управления выпусками для некоторых PHP-приложений, которые я использую.

По сути, план состоит в том, чтобы сохранить каждый выпуск в /home/release/1.x и т.д. (экспортированный из тега в SVN), а затем сделать символическую ссылку на / live_folder и изменить корень документа в конфигурации apache.

У меня нет проблем с настройкой всего этого (на самом деле у меня это работает на данный момент), однако я разработчик с базовыми знаниями в области администрирования сервера.

Есть ли что-нибудь, о чем мне нужно знать с точки зрения безопасности или производительности при использовании этого метода управления выпусками?

Спасибо

Если вас действительно беспокоит проблема производительности (минимальная) символической ссылки, вы всегда можете использовать привязать крепление вместо. Вы также не будете иметь никаких последствий для безопасности. Bind-mount - это, по сути, символическая ссылка, которая существует исключительно на уровне ядра.

Но вам, вероятно, не стоит беспокоиться об аспекте производительности, если у вас нет доказательств того, что это реальная проблема.

Кроме того, фактическое включение символических ссылок в Apache в некоторых случаях фактически улучшает производительность, поскольку некоторые проверки файловой системы удалены. Если у вас нет причин для его отключения, вы, вероятно, захотите включить FollowSymLinks.

См. Раздел настройки производительности о символических ссылках в документации Apache. http://httpd.apache.org/docs/2.2/misc/perf-tuning.html#symlinks

FollowSymLinks и SymLinksIfOwnerMatch

Везде, где в вашем URL-пространстве у вас нет Options FollowSymLinks или у вас есть Options SymLinksIfOwnerMatch, Apache должен будет выполнить дополнительные системные вызовы для проверки символических ссылок. Один дополнительный вызов для каждого компонента имени файла.

Последствия использования FollowSymLinks для безопасности, как правило, сосредоточены вокруг предоставления ненадежным пользователям возможности создавать файлы. Если вы находитесь на общем сервере, если вы разрешаете недоверенным пользователям писать в файловую систему, или если у вас есть какие-либо ошибки в каких-либо размещенных веб-приложениях, то враждебный пользователь может создать символическую ссылку на файл, который обычно не доступно через веб-сервер. Они могут отобразить его, или, если ваши разрешения действительно плохие, и у вас есть ошибочное веб-приложение, тогда символическая ссылка может разрешить изменения. В системе, которая хорошо заблокирована, это не должно быть большой проблемой. Если у вас есть какие-либо каталоги, в которых вы разрешаете хранить пользовательский контент, вам следует отключить следующую за ними символическую ссылку.

одна символическая ссылка на правильный каталог вообще не повредит производительности, потому что она будет кэшироваться VFS.

Что касается соображений безопасности, вам может потребоваться включить символическую ссылку на вашем сервере, которая мог стать проблемой. Первое, что нужно сделать, это отключить символическую ссылку, следующую за ссылкой на каталог приложения. Однако я думаю, что лучше иметь надлежащее решение с полной безопасностью, которое гарантирует, что все приложения имеют только те разрешения, которые им нужны - например, вы можете запускать свои приложения PHP под их собственными учетными записями с помощью FastCGI.

Символические ссылки снижают производительность, поскольку диск должен искать в двух местах (или более, если есть несколько ссылок, по которым нужно следовать), чтобы прочитать файл. Кроме этого, это не должно быть проблемой. Я не осведомлен о каких-либо последствиях для безопасности ...