bibilink, Про те случаи я написал в сообщении 25. Но повторю ещё раз: если ты можешь читать директории других юзеров (именно юзеров, а не как ты показал в этой теме - систему) - это уже действительно проблема. Что-то мне кажется, что там, где у тебя это получалось - не был установлен mpm-itk. И это уже действительно повод волноваться. А тут, где ты сейчас проверял (что нет доступа к соседу) - все ок.

bibilink, ты, наверное, хотел сказать, что ты можешь прочитать свой каталог юзера, а другие не можешь? Тогда все ок. Естественно ты можешь читать свой каталог (ведь процесс запускается от твоего имени (скорее всего. Все уже itk используют) владелец процесса = владельцу каталога. Соответственно доступ есть) и не можешь читать каталог другого юзера (так как владелец процесса != владельцу того каталога). Раньше, когда mpm-itk не использовался (когда его ещё не было) - бывали случаи, что можно было переходить (так как все процессы запускались от 1го юзера: apache)
Добавлено 04.08.16 в 10:25:55:
так что все ок там, где бы ты не проверял сейчас это

bibilink, давай я тебе просто скину этот линк:
http://joomla-book.ru/blog/filesystem-permissions-or-777-is-bad

Возможно станет чуток понятнее суть

bibilink, Это не столько от хостинга зависит, сколько от используемой ОС

upd: и ПО

Tony, что именно небезопасно? В примере он не показал чтение каталога ЮЗЕРА. Он лишь показал системные катологи (которые общедоступны, что бы юзеры могли пользоваться так сказать благами системы). Вот если он прочитает каталог юзера - тогда стоит сообщить хостеру об этом, так как это уже да, проблема

Tony, об этом я написал в сообщении 25. Что:
---
Другое дело, если ты выходишь, читаешь из etc/password логин юзера, а затем (пример):
../../../../../../var/www/$username (где $username - какой-нибудь логин из password)
тебе показывает листинг. Вот это уже фигово (в идеале должна быть белая страница или сообщение об ошибке, смотря как ты скрипт написал), что ты можешь лазить по папке другого юзера
---

bibilink, Это никому ничегог не даст. Строение ОС в принципе одинаковое и не несет никакой инфы. Я тебе эти папки мог перечислить без всякого сканирование и угадал бы 90% из них. Это стандарт. То же самое как C:\Windows/System32 и так далее. . etc/shadow закрыт. значит всё ок. Доступа к хешам паролей ты не получил.

Я тебе больше скажу:
от юзера до корня файловой системы ты можешь выходить на просмотр (и в некоторые смежные директории). Это не является проблемой. Так уж устроена ОС.

Другое дело, если ты выходишь, читаешь из etc/password логин юзера, а затем (пример):
../../../../../../var/www/$username (где $username - какой-нибудь логин из password)
тебе показывает листинг. Вот это уже фигово (в идеале должна быть белая страница или сообщение об ошибке, смотря как ты скрипт написал), что ты можешь лазить по папке другого юзера. А то, что ты можешь читать общедоступные папки модулей - это ерунда бесполезная. Главное, как я уже сказал, что бы редактировать не давало
Добавлено 04.08.16 в 10:09:53:
зачстую панику поднимают люди, кто не понимает вообще принципа работы Linux'а. Не знают что такое user:group и chmod. Они почему-то считают, что они должны мочь смотреть только свою папку, а все остальное - дыра. Нет, это не так. Если закрыть юзеру для чтения подобные пути - у него не будет доступа к интерпретатору, к базам и так далее, так как система будет запрещать процессу, запущенному от имени юзера доступ к каталогам эти модулей.

bibilink, причем это похоже не на /root а на сам корень ФС. Естественно он читаем при определенном раскладе. Так как он вообще общий как таковой. Для всех и всего

bibilink, и что это даст? на практике пожалуйста. Некоторые модули иногда ставятся в /root (хотя немного глупо, конечно)

bibilink, уязвимостью не является доступ к /etc/passwd , остальное нужно смотреть к чему именно есть доступ. К некоторым системным файлам (на чтение) доступ действительно не является дырой. Потому что есть файлы, которым нужно, что бы они могли читаться различными сервисами (например сервером бд mysql или же php интерпритатором. Или же сервером teamspeak'а и так далее). Обеспечить возможность чтения можно только разрешив чтение "для всех". Но как правило информация в этих файлах бесполезна. Список юзеров толком ничего не может дать (другое дело, как я уже сказал, если читается etc/shadow , где хранятся хеши паролей юзеров), а в остальных случаев то же самое, зачастую, можно узнать из phpinfo (такое как набор модулей и/или домашние директории модулей). И совсем другое дело, если данные файлы разрешены для редактирования. Вот тогда да - это проблема. Причем не хилая