Общая небезопасная настройка PHP?

Я работаю с системным администратором в университете и просто наткнулся на что-то, что, вероятно, распространено, но было для меня шоком.

Все каталоги public_html и веб-области хранятся в afs с разрешениями на чтение для веб-серверов. Поскольку пользователям разрешено иметь php-скрипты в своем public_html, это означает, что они могут обращаться к файлам друг друга изнутри php (и основных веб-файлов!).

Это не только делает бесполезной любую защиту паролем .htaccess, но также позволяет пользователям читать исходные файлы php, содержащие пароли базы данных mysql и аналогичную конфиденциальную информацию. Или, если они обнаружат, что у других людей есть каталоги, к которым веб-серверы имеют доступ для записи (например, для личных журналов или для сохранения отправленных данных формы), они могут хранить файлы в этих учетных записях.

Простой пример:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

Это общая проблема? И как вы обычно это решаете?

ОБНОВИТЬ:

Спасибо за вклад. К сожалению, кажется, нет простого ответа. В большой общей среде, такой как эта, пользователям, вероятно, не следует предоставлять такой большой выбор. Лучший подход, который я могу придумать, - это установить open_basedir в основной конфигурации для всех каталогов public_html, запустить suphp и разрешить только чистый php (без сценариев cgi, запуска внешних команд с обратными галочками и т. Д.).

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

Можно использовать suphp, который запускает скрипт php с идентификатором своего владельца.

http://www.suphp.org

Я бы предложил ограничить доступ PHP к файлам (через open_basedir& подобные директивы, для каждого хоста): вы хотите, чтобы пользователи могли открывать / читать / записывать файлы под своим рутом и, возможно, на один уровень выше (для нуля) пространство), но не каталог, в котором они будут хранить, например, htpasswdфайлы.

Структура каталогов, например:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Соответствует этому требованию: open_basedirможет быть /Client/siteбезопасно указано , и htpasswdфайлы хранятся в /Client/auth(с .htaccessфайлами или httpd.confизменены, чтобы указывать вместо этого в соответствующем месте).
Это препятствует тому, чтобы ваши клиенты открывали чьи-либо файлы, и в качестве преимущества злоумышленники не могут читать содержимое /Client/auth(или что-либо еще в вашей системе, например /etc/passwd:-)

Смотрите http://php.net/manual/en/ini.core.php для получения дополнительной информации о реализации open_basedir & per-vhost.

Нет, это не распространенная проблема, поскольку большинство общих хостов определяют конфигурацию open_basedir в файле htaccess в каталоге public_html каждого пользователя (или в vhost, если у каждого пользователя есть собственный vhost).

например, файла .htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Но убедитесь, что вы установили правильные разрешения для файла .htaccess, чтобы предотвратить изменение пользователем open_basedir (если они пытаются переопределить его в subdir / .htaccess, это не должно работать - но вам, вероятно, следует проверить это, чтобы убедиться) ,

НТН

C.

AFS игнорирует простые пользовательские разрешения Unix. suPHP выполняет setuid перед запуском программы php, но это не дает процессу токенов kerberos, необходимых для доступа к AFS, и ограничивается его разрешениями. Для получения этих токенов необходимо было бы каким-то образом изменить suPHP, прежде чем он сможет представить себя в системе AFS в качестве этого пользователя. Насколько я знаю, это не было сделано. (На самом деле, я нашел этот вопрос, когда смотрел, сделал ли это кто-нибудь еще.)