Я работаю с системным администратором в университете и просто наткнулся на что-то, что, вероятно, является обычным, но было для меня настоящим шоком.
Все каталоги 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 с uid его владельца.
Я предлагаю ограничить доступ 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, это не должно работать - но вам, вероятно, следует проверить это, чтобы убедиться) .
HTH
С.
AFS игнорирует простые разрешения пользователей unix. suPHP выполняет setuid перед запуском программы php, но это не дает процессу токены kerberos, необходимые для доступа к AFS, и ограничивать его разрешениями. suPHP необходимо каким-либо образом изменить, чтобы получить эти токены, прежде чем он сможет представить себя системе AFS как этот пользователь. Насколько мне известно, этого не было сделано. (Фактически, я нашел этот вопрос, когда смотрел, делал ли это кто-нибудь еще.)