не кто угодно, а только тот, кто в твоей группе - например, nginx
в том, что у других пользователей доступа нет, только у nginx
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Chrooted php-fpm, как давать доступ нжинксу?
- Автор темы Фанат
- Дата начала
То есть, фишка в том, что мы nginx добавляем в группу каждого пользователя?
создали пользователя foo:foo и сразу пишем uermod -a -G foo nginx
так?
Можно отозвать права. Создаете группу "users", в него включаете пользователей всех , которые есть на сервере (не системные пользователи, а тех что добавили на сервер). И ставите доступ на хоум пользователя 0701
(например /var/www/user1) , при этом делаете владельцем директории /var/www/user1 user:users (владелец user, группа users). Т.е., те кто входят в группу users не смогут ходить в директорию (права 0), а вот юзер www-data (exim, dovecot и другие имеют права x) смогут попадать вглубь
Я бы не добавлял пользователей в группу www-data, а методом исключения (как указал выше). Это общепринятый стандарт ограничения доступа.
(например /var/www/user1) , при этом делаете владельцем директории /var/www/user1 user:users (владелец user, группа users). Т.е., те кто входят в группу users не смогут ходить в директорию (права 0), а вот юзер www-data (exim, dovecot и другие имеют права x) смогут попадать вглубь
Я бы не добавлял пользователей в группу www-data, а методом исключения (как указал выше). Это общепринятый стандарт ограничения доступа.
Вот это прикол!
Я правильно понял, что если два пользователя входят в одну и ту же группу, то для них проверяются только права на группу, и если стоит запрет, то права "для всех" уже не применяются?
То есть, алгоритм проверки прав получается такой - сначала матчим тип (юзер, группа, все), а потом для полученного типа проверяем права?
Чёрт, это уже интересно! Кажется, это как раз именно та изюминка, которую я никак не мог понять до сих пор.
Это гарантированное поведение? Щас попробую погуглить.
MiksIr
miksir@home:~$
Общепринятый - это общекем? Стандарт - это RFC? По мне такое решение я видел лишь однажды году так в 96-м и уже тогда оно показалось чем-то вроде заднего прохода. Больше такого не встречал, даже на бородатых хостингах.
MiksIr
miksir@home:~$
Как-то непонятно сформулированно. Сначала проверяем совпадает ли uid процесса и uid файла, если да - используем его, если нет - проверяем, входит ли юзер uid процесса в группу gid файла, если да - используем права группы, если нет - используем права "остальные".
Дк, так делает ISPManager. У них группа mgrsecure (включает всех не системных пользователей).
Смысл идет такой:
1. Есть группа mgrsecure, в нее включены пользователи user1, user2, user3, user4
Есть хоум пользователя /var/www/user1 c правами dr-x-----x , далее - выполняя от имени юзера (user1) применяются права r-x , а если от имени user2, то ставятся права ---, от имени www-data (не входящего в mgrsecure) права будут --x
Вот, они даже доку накидали http://ru.ispdoc.com/index.php/Работа_с_пользователями_и_группами
Смысл идет такой:
1. Есть группа mgrsecure, в нее включены пользователи user1, user2, user3, user4
Есть хоум пользователя /var/www/user1 c правами dr-x-----x , далее - выполняя от имени юзера (user1) применяются права r-x , а если от имени user2, то ставятся права ---, от имени www-data (не входящего в mgrsecure) права будут --x
Вот, они даже доку накидали http://ru.ispdoc.com/index.php/Работа_с_пользователями_и_группами
Ок, какое у вас решение? По мне , так решение от ISPManager логичное. Больше не знаю.
Ну да, у меня коряво алгоритм насписан. Но я имел в виду его ключевой момент - что нет фолбэка на уровень ниже, вида "совпадает уид, но для него нет прав - проверим группу". Для меня это почему-то не было очевидно.
MiksIr
miksir@home:~$
В общем понятно, да, костыль для старых дистрибутивов http://www.j3e.de/ngroups.html
MiksIr
miksir@home:~$
Не, такого нет.
MiksIr
miksir@home:~$
Оно тут описано. У пользователя каждого своя группа. В эту группу входит так же веб-сервер. Права доступа вебсервера регулируется правами группы. Хотя ACL мне кажется еще более логичным, но теоретически его, наверно, можно попортить...
Ну а как с системными процессами? Например тот же debian-exim, dovecot? Придется добавлять юзера во все необходимые группы, и не факт что не забудешь. А так - методом исключения. Хз, сколько ISPManager'ов по миру стоит и нет никаких проблем.
Ну, я бы сказал, что не "ispmanager", а "хостинг". Решение представляется мне разумным. Ту же дисковую квоту удобнее считать, когда все в одном месте.
господа, мы смогли близко к тексту повторить обсуждение, которое было на первых двух страницах - редкий случай для этого форума
в реальности нет ни проблемы добавить 10 системных юзеров в 100 групп, ни 100 юзеров в одну, и всегда найдутся дятлы, которые выставят себе 777
в реальности нет ни проблемы добавить 10 системных юзеров в 100 групп, ни 100 юзеров в одну, и всегда найдутся дятлы, которые выставят себе 777
Последнее редактирование:
MiksIr
miksir@home:~$
Обычно почтовые сервера живут вообще отдельно. Ибо все же вебмастер, работающий с сайтом, и генеральный директор, получающий почту... не уверен, что должны пересекаться. Да и с квотой проблема - файлы то от того же "dovecot" будут юзера dovecot, а квоты же на юзера. А если доставщик почты будет делать suid, то и никакие доп. права не нужны.
MiksIr
miksir@home:~$
На самом деле что там внутри у человека - пофиг, хоть 777, главное, что бы в пути была одна директория с нужными правами. И не дать пользователю ее трогать. А это можно сделать и несколькими способами.
AnrDaemon
Продвинутый новичок
Для каталога права расшифровываются следующим образом:
R = directory liting allowed
W = object creation and directory (itself) deletion allowed
X = directory traversal allowed
Так что можно поставить +X-R и в каталог можно будет зайти, но нельзя будет увидеть его содержимого. К безопасности это никакого отношения, конечно, не имеет. Но от любопытных глаз прикроет.