ACL в линукс, наследование разрешений
Есть в Генту такой пакет sys-apps/acl - Access control list utilities похожие на те, что существуют в NT.
Пытаюсь при помощи ACL выстроить красивую и логичную систему разрешений, для файлового сервера Подразделения, в котором три отделения.
Вариант первый, используем наследование и запреты
СТруктура папок
Группа1
Группа 1.1, Группа 1.2, Группа 1.3
Юзер 1.1.1, Юзер 1.1.2; Юзер 1.2.1, Юзер 1.2.2, Юзер 1.2.3; Юзер 1.3.1
Итак, на корневую папку ставим разрешить всем все и дочерним папкам наследовать разрешения
На папку Группы 1.1 ставим запрет для групп Группа 1.2, Группа 1.3
На папку Юзер 1.1.1 ставим запред для Юзер 1.1.2
Мучения начинаются как только Юзер 1.1.1 захочет открыть доступ к подпапке в своей папке для любого другого пользователя или для всей группы.
В этом случае вся стройная картинка с наследованием прав летит к чертям и в случае миграции в другой домен нужно будет проверять руками не только папки пользователей но все папки верхнего уровня.
Можно попробовать расположить папки пользователей на первом уровне, а общие папки для подразделений и отделений на втором и третьем уровне и сделать симлинки в папку каждого пользователя, но тогда черт сломает ногу в симлинках, особенно если нужно будет окрывать файлы для нескольких пользователей из разных подразделений.
Подскажите существуют ли готовые решения или схемы как красиво организовать файловое хранилище для большого числа пользователей разбитых группы, подгруппы и подпод группы. Большинство знакомых админов довольствуются файловой помойкой, упорядочивая только небольшие участки, в которых хранятся важные данные.
- Для комментирования войдите или зарегистрируйтесь
В качестве
В качестве собственно файлового сервера какое решение предполааешь использовать?
--
Live free or die
Скорее всего
Скорее всего linux + samba
В переводе на
В переводе на общедоступный с вероятностью 97% в качестве LDAP-сервера - OpenLDAP.
--
Live free or die
Мудро. А как на
Мудро.
А как на счет вопроса который я задал, ACL?
Добавляем
Добавляем группы
groupadd group11
groupadd group12
Создаем директории
mkdir group1
mkdir group1/group11
mkdir group1/group12
chmod 755 -R group1
chown root:root -R group1 - для красоты... все равно сейчас добавим acl'ы
setfacl -R -m g:group11:rwX group1/group11
setfacl -R -m g:group12:rwX group1/group12 - добавили acl, чтоб те кто в группе могли писать в свои директории
setfacl -R -d -m g:group11:rwX group1/group11
setfacl -R -d -m g:group12:rwX group1/group12 - по умолчанию ставим права
После такого все пользователи в группе group11 смогут писать в group1/group11 ну и группа 2 аналогично.
Со всем этим
Со всем этим получается какая-то чепуха.
Если работать через самбу, то для шары указываем:
Начинаем раздавать права:
С исходной папкой разобрались. Теперь, юзеры:
Когда в винде логинится юзер b, то он не может писать в папку test, но может просматривать ее содержимое. Когда то же самое делает h, то он может создать папку или файл в test/ и просматривать содержимое.
Итак, h создал файл:
который может прочитать, но не удалить пользователь b, и папку
которую пользователь b не может удалить, но может открыть (что правильно) и создать в НЕЙ (!!) свою папку
а также, может удалить все папки, лежащие в test/qwer/ и созданные не им, а пользователем h. Как это решить, до сих пор не понимаю. Пробовал маски менять, не помогло. Костыль в виде периодически повторяющегося скрипта
очень не хочется использовать, т.к. получается большая дырка. Как заставить этот acl правильно работать?
Теперь, я пробую работу с acl, логинясь прямо на сервер.
Юзеры те же самые.
Создал пользователем h файл и папку:
но тут получается еще хуже. Несмотря на то, что b не могжет удалить файл и папку, он может записывать в файл (!??) и создавать файлы-папки в qwer2/, а также спокойно удалять их, не взирая на права и маски. Почему?
Все тестовые примеры в винде создавались из контекстного меню папки, а в линуксе командами mkdir и touch. Все права, которые видны, назначены системой автоматически.
У самбы свои
У самбы свои ACL;
Аналог понятия в W2k3 доступ: локально и на шары друг к другу отношения практически не имеет
Проблема
Проблема решена.
Хозяином директории-файла становится root:root и все работает так, как надо. Это в самбе.