man setfacl -> default, Luke.

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

Последуй совету, почитай ман.

Да, почитал 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 мог читать и писать в эти файлы В ЛЮБОМ СЛУЧАЕ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И на права тогда будет совсем пофигу.

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

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

kill

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

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

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

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

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

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

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