Наследование ACL
Есть такая проблема:
есть раздел на xfs, на котором лежат каталоги разных пользователей (не домашний). Требуется, чтобы все файлы, создаваемые одним пользователем в своем каталоге были доступны на запись и некоему другому пользователю, а остальным — только на чтение или вообще запрещены.
Можно, конечно, создать общую группу и поставить umask в значение, разрешающее запись для членов группы, но проблема в том, что все остальные пользователи _уже_ объединены в общей группе, и, значит, они тоже смогут писать в файлы.
Если быть более детальным, то это раздел предназначен для расчетов и научный руководитель хочет иметь права писать в файлы своих студентов. Понятно, что остальные пользователи машины, в общем, писать туда не должны. Но беда в том, что все пользователи, ведущие расчеты, уже объединены в группу, для которой дано несколько больше прав, чем всем остальным. Т.е. нужно еще более тонкое разделение прав. Пытаюсь реализовать это на уровне ACL, но пока не понимаю, как сделать так, чтобы некоторый лист прав доступа автоматически присваивался и вновь создаваемым файлам. (что-то вроде наследования прав в Винде).
Re: Наследование ACL
man setfacl -> default, Luke.
Re: Наследование ACL
Вы не совсем меня поняли. Я знаю, как поставить ACL на существующие файлы. Я хочу, чтобы все создаваемые _новые_ файлы имели ACL тот, который мне нужен, а не тот, который по умолчанию. _Наследование_ ACL, например от каталога, в котором этот файл расположен, работает?
Re: Наследование ACL
Последуй совету, почитай ман.
Re: Наследование 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 мог читать и писать в эти файлы В ЛЮБОМ СЛУЧАЕ?
Re: Наследование ACL
Файлы читаются/пишутся по сети? Если да, то подними samba,ftp.
В ЛЮБОМ СЛУЧАЕ
2. В любом случае владелец имеет право менять аттрибуты (setfacl -x). Т.о. если нужно именно «в любом случае»(*) — нужно либо уговорить прогу, создающую файлы, создавать их с другим владельцем, либо прогу читающую — игнорировать права доступа. Или сбрасывать все права в умолчательные при логине шефа.
(*) Однако, если владелец не хочет и знает, как этого добиться, скорее всего у него хватит мозгов зашифровать или унести свои файлы, т.ч. вряд ли такое желание шефа удовлетворимо.
Re: В ЛЮБОМ СЛУЧАЕ
> Однако, если владелец не хочет и знает, как этого добиться, скорее всего у него хватит мозгов зашифровать или унести свои файлы, т.ч. вряд ли такое желание шефа удовлетворимо.
Про mask я прочитал. Но посмотрите внимательно на приведенные мной примеры: насколько я понял, значение mask у вновь созданного файла берется из значения umask, а не наследуется от родительского каталога (исправьте меня, если я неправ). Если бы маска наследовалась от родительского каталога, не было бы проблемы: выставив ее в значение rwx, всегда можно добиться, чтобы права пользователя chief были такие, как надо.
А вопрос не в том, чтобы любой ценой понять, чем занимается человек, а в том, что этот человек (студент) по неопытности делает много ошибок (во входных файлах расчетов), и иногда требуется их исправить (руководителю). Руководитель — не я и мне совсем не хочется выполнять чужую работу. Не root’ом же этого руководителя делать!
Наследование прав доступа от родительского каталога
Есть директория /srv/sites/domain.ltd/html принадлежащая пользователю и группе apache:apache и имеющая права 6770 (rwsrws—). Есть юзер iskatel, который входит в группу apache и он создаёт в этой директории файл, скажем, index.html. Файл автоматом получает принадлежность к юзеру iskatel и группе apache. А я вот ожидал другого результата, ведь наличие suid и sgid битов на каталоге должно приводить к тому что файл у родительского каталога будет наследовать и группу и юзера, то есть юзер должен быть apache. Почему так?
Потому что suid не работает для каталогов.
Бит setuid, установленный для директорий, игнорируется в большинстве версий Unix[источник не указан 1468 дней].
А какие тогда есть способы получить желаемое?
Cоздавайте файл пользователем apache. Но полагаю chown будет удобнее.
Каждый раз делать chown? А представь, что юзеру права рута, чтобы использовать chown, не даются. А вообще это же вечная проблема в линуксе, когда два юзера пишут в один каталог с одинаковыми правами. Вот например юзер по ftp создаёт файлы от имени iskatel, php-скрипты создают файлы от имени apache. Вообще случай с веб-сервером — это частный случай. Другой случай, когда имеется файлопомойка в которой создают файлы различные сотрудники одного отдела, если один случайно создаст файл read-only — то второй не сможет его удалить. Я не верю, что за столько лет существования линукса никто не научился решать эту проблему.
Другой случай, когда имеется файлопомойка в которой создают файлы различные сотрудники одного отдела, если один случайно создаст файл read-only — то второй не сможет его удалить.
Если оба юзера входят в группу, являющуюся группой-владельцем этого файла, то сможет.
Если пользователь не входит в группу wheel — вообще не стоит менять права и владельца в будущем, это поможет более менее контролить «файло-помойку». ftp и web чуточку отличаются. На ftp сервере владельца менять не стоит, а на web сервере создавать файлы скриптом (права apache).
если один случайно создаст файл read-only — то второй не сможет его удалить. Я не верю, что за столько лет существования линукса никто не научился решать эту проблему.
проблемы нет. один отдел — одна группа, все пользователи этой группы имеют равные права на файлы и могут использовать chmod. Заблокировать файл можно только с помощью chown, а значит пользователь должен входить в группу wheel. Не стоит подключать к этой группе всех подряд, также не стоит подключать рядового пользователя более чем к одной группе.
P.S. Надо поэксперементировать с этим )
Каждый раз делать chown? А представь, что юзеру права рута, чтобы использовать chown, не даются.
Можно использовать bindfs, что-то вроде:
/home/alex/projects /home/dev/projects fuse.bindfs create-for-user=alex,create-for-group=alex,force-group=dev,force-user=dev,perms=g+rwX 0 0 Наследование прав директории linux
Создаю папку например /tmp/foo . Выставляю на неё права 775 . Соответственно для этого выполняю chmod -R 775 /tmp/foo . Владельцем делаю пользователя myuser и группу mygroup : chown -R myuser:mygroup /tmp/foo . Это ясно и понятно. Но есть задача: все новые файлы и папки (условно-бесконечная вложенность) внутри /tmp/foo должны наследовать от неё владельца и права доступа. Если я создам например файл /tpm/foo/bar.txt у него должны быть так-же права 775 и владелец myuser группа mygroup . Даже если файл создаёт другой пользователь из группы mygroup . Пробовал делать chmod -R 4775 /tmp/foo всё равно у создаваемого внутри файла права 755 и владелец otheruser группа otheruser . Названия юзеров и групп условные. Что я делаю не так?
Каталог монтируемый? Если да, то права необходимо выставлять после монтирования. И права устанавливаются при создании файла/каталога, к сведению.
@Adokenai про права после монтирования знаю. Нет, каталог не монтируемый. Он создаётся раз и навсегда. А про права при создании.. не совсем понимаю. mkdir с параметром -m ? Ну.. ок. А если после создания сделать chmod это не то?
когда права назначены, то для новых каталогов и файлов используются права создателя. То есть от чьего имени было создано, тот и владелец. chmod можно сделать всегда. P.S. если речь о tmpfs, то там свои заморочки, ибо временный каталог в памяти.
Это невозможно. Владелец всегда тот, кто создает. Права же ставятся те, которые указаны в umask пользователя.
1 ответ 1
Но есть задача: все новые файлы и папки (условно-бесконечная вложенность) внутри /tmp/foo должны наследовать от неё владельца и права доступа.
Если коротко, то наследовать владельца невозможно (без изменений в ядре linux) и по большей части лишено практического смысла. В linux, как и в большинстве unix-подобных ОС, установка бита setuid на каталоге не даёт никакого эффекта — владельцем всегда является создатель файла.
С другой стороны можно наследовать группу файла, для этого используется бит setgid :
После этого подкаталоги/файлы будут наследовать группу и бит setgid , но права всё же будут определяться umask ‘ом пользовательских процессов. Для того чтобы задать права по умолчанию, можно установить значения «ACL по-умочанию» (default ACL).
setfacl -m d:u::rwx /tmp/foo setfacl -m d:g::rwx /tmp/foo Эти значения действуют аналогично ~umask (т.е. дополнению к umask ‘у) в данном каталоге, модифицируя права запрошенные процессом при создании файла/подкаталога. Т.е. любой процесс может запросить создание файла с меньшими правами, но обычно большинство программ пытается создать файл с правами 0666 , а каталоги с 0777 . Эти значения также наследуются подкаталогами.