LINUX.ORG.RU
ФорумAdmin

Наследование ACL


0

0

Есть такая проблема:
есть раздел на xfs, на котором лежат каталоги разных пользователей (не домашний). Требуется, чтобы все файлы, создаваемые одним пользователем в своем каталоге были доступны на запись и некоему другому пользователю, а остальным - только на чтение или вообще запрещены.
Можно, конечно, создать общую группу и поставить umask в значение, разрешающее запись для членов группы, но проблема в том, что все остальные пользователи _уже_ объединены в общей группе, и, значит, они тоже смогут писать в файлы.

Если быть более детальным, то это раздел предназначен для расчетов и научный руководитель хочет иметь права писать в файлы своих студентов. Понятно, что остальные пользователи машины, в общем, писать туда не должны. Но беда в том, что все пользователи, ведущие расчеты, уже объединены в группу, для которой дано несколько больше прав, чем всем остальным. Т.е. нужно еще более тонкое разделение прав. Пытаюсь реализовать это на уровне ACL, но пока не понимаю, как сделать так, чтобы некоторый лист прав доступа автоматически присваивался и вновь создаваемым файлам. (что-то вроде наследования прав в Винде).

Ответ на: комментарий от e

Вы не совсем меня поняли. Я знаю, как поставить ACL на существующие файлы. Я хочу, чтобы все создаваемые _новые_ файлы имели ACL тот, который мне нужен, а не тот, который по умолчанию. _Наследование_ ACL, например от каталога, в котором этот файл расположен, работает?

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от DonkeyHot

Да, почитал man, там не все ясно написано, пришлось читать еще и amn 5 acl :)

Результаты следующие:
Для того, чтобы добавлять специфический ACL на файлы,
созданные в каталоге, нужно добавить записи о default ACL 
с помощью ключа sefacl -d

Что сделал:
1. добавил правильный ACL на каталог

$ setfacl -m u:chief:rwx,g::r-x,o::r-x,m::rwx /calc.student
$ getfacl calc.student/
# file: calc.student
# owner: student
# group: users
user::rwx
user:chief:rwx
group::r-x
mask::rwx
other::r-x

2. Поставил дефолтный ACL
$ setfacl -d -m u:chief:rwx,g::r-x,o::r-x,m::rwx /calc.student
$ getfacl calc.student/
# file: calc.student
# owner: student
# group: users
user::rwx
user:chief:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:chief:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

3. Проверил, что файлы, создаваемые в этом каталоге имеют правильные права:
$ cd calc.student
$ touch file1
$ getfacl file1
# file: file1
# owner: student
# group: users
user::rw-
user:chief:rwx                 #effective:rw-
group::r-x                     #effective:r--
mask::rw-
other::r--

Да, все правильно, шеф может писать и читать в файл. И удалять его.

НО!
$ chmod 600 file1
]$ getfacl file1
# file: file1
# owner: student
# group: users
user::rw-
user:chief:rwx                 #effective:---
group::r-x                     #effective:---
mask::---
other::---

То есть шеф теперь не может ни редактировать файл, ни даже читать его, хотя
может его удалить!

Как бороться с этим? Другими словами, как _гарантировать_,
чтобы пользователь chief мог читать и писать в эти файлы В ЛЮБОМ СЛУЧАЕ?

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

В ЛЮБОМ СЛУЧАЕ

1. Читай там же про mask

2. В любом случае владелец имеет право менять аттрибуты (setfacl -x). Т.о. если нужно именно "в любом случае"(*) - нужно либо уговорить прогу, создающую файлы, создавать их с другим владельцем, либо прогу читающую - игнорировать права доступа. Или сбрасывать все права в умолчательные при логине шефа.

(*) Однако, если владелец не хочет и знает, как этого добиться, скорее всего у него хватит мозгов зашифровать или унести свои файлы, т.ч. вряд ли такое желание шефа удовлетворимо.

DonkeyHot ★★★★★
()
Ответ на: В ЛЮБОМ СЛУЧАЕ от DonkeyHot

> Однако, если владелец не хочет и знает, как этого добиться, скорее всего у него хватит мозгов зашифровать или унести свои файлы, т.ч. вряд ли такое желание шефа удовлетворимо.

Про mask я прочитал. Но посмотрите внимательно на приведенные мной примеры: насколько я понял, значение mask у вновь созданного файла берется из значения umask, а не наследуется от родительского каталога (исправьте меня, если я неправ). Если бы маска наследовалась от родительского каталога, не было бы проблемы: выставив ее в значение rwx, всегда можно добиться, чтобы права пользователя chief были такие, как надо...

А вопрос не в том, чтобы любой ценой понять, чем занимается человек, а в том, что этот человек (студент) по неопытности делает много ошибок (во входных файлах расчетов), и иногда требуется их исправить (руководителю). Руководитель - не я и мне совсем не хочется выполнять чужую работу. Не root'ом же этого руководителя делать!

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от SlavikSS

> Файлы читаются/пишутся по сети? Если да, то подними samba,ftp,...

нет, пользуемся терминальным доступом - по ssh

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

А, вот еще проблема: некоторые программы, например mc, игнорируют значения umask и по Shift-F4 (создать новый файл) создают его с правами 644 - вот типичная проблема. А старые версии dos2unix вообще ставят 600!

Вот собрал человек входник на Винде, перенес его на расчетный комп, сделал dos2unix - и опля! - никто этот файл уже не прочтет. А хотелось бы, чтобы попадая в заданный каталог файл _всегда_ получал атрибуты, позволяющие определнному пользователю его прочесть.

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

>Про mask я прочитал

А default mask попробовать?

>не было бы проблемы ... всегда можно добиться, чтобы права пользователя chief были такие, как надо

Проще сделать так, как в первом варианте, без ACLей: umask, понасоздавать каталоги для каждого студента с владельцем студент:chief(группа из одного шефа), правами ug=rwx, указать -o grpid при монтировании ФС (если это не включено по умолчанию), и попросить студентов не трогать права без надобности.

DonkeyHot ★★★★★
()
Ответ на: комментарий от Valmont

> Любим мы себе сложности делать. Может быть таки sudo для шефа проще прикрутить?

Sudo на какую команду, а?

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

Ну блин, вам все по полочкм разложи :) например на su, выключив через pam возможность делать su на определенных пользователей, типа рута и т.д. Или на перловый триггер, который на себя возмет роль выяснения можно не можно делать su.

Если задуматься, можно много чего придумать :)

Это в том случае, если с sudoedit нельзя застраховать себя от подстак симлинками и т.д.

Valmont ★★★
()
Ответ на: комментарий от Valmont

> Если задуматься, можно много чего придумать :)

Это воистину правда! :)

Я, кажется, достаточно формализовал задачу, чтобы было ясно, что копать нужно в сторону работы с правами на файлы. Либо я чего-то недопонимаю, либо система разграничения доступа к файлам в Linux не позволяет решить эту задачу. А значит - костыли, возможно даже и с sudo :)

annoynimous ★★★★★
() автор топика
Ответ на: комментарий от annoynimous

Возможно, если с читого листа решать задачу, то ее можно было бы решить на этом уровне. А при существующих условиях скорее всего нужно копать куда-то еще :)

Valmont ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.