Почему cp не уважает ACL?

15

Распространенный способ настроить каталог для обмена файлами внутри группы:

$ mkdir foo
$ chgrp felles foo
$ chmod g+ws foo
$ setfacl -m group:felles:rwx foo
$ setfacl -dm group:felles:rwx foo

Это гарантирует, что все созданные файлы fooдоступны для чтения и записи для группы felles:

$ umask
0022
$ echo hi > foo/bar
$ ls -l foo
total 4
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar

Однако, если вы копируете файл foo, ACL по умолчанию не применяются:

$ echo you > baz
$ cp baz foo/
$ ls -l foo
total 8
-rw-rw-r--+ 1 bhm felles 3 2010-09-23 00:18 bar
-rw-r--r--+ 1 bhm felles 4 2010-09-23 00:19 baz
$ getfacl foo/baz
# file: foo/baz
# owner: bhm
# group: felles
user::rw-
group::rwx          #effective:r--
group:felles:rwx        #effective:r--
mask::r--
other::r--

Почему это происходит, и есть ли способ обойти это?

( Перемещение файла в каталог не относится ни к спискам ACL, ни к принадлежности группы, но я могу понять, почему: вам может не потребоваться изменить права доступа к файлу просто потому, что вы изменили его имя.)

BHM
источник
serverfault.com/a/452678/46333 этот ответ содержит хорошее объяснение.
Каан

Ответы:

11

Если cpсоздает файл назначения, он копирует разрешения исходного файла, за исключением битов, которые установлены в umask. Это стандартное поведение (см., Например, шаг 3.b в спецификации Single Unix v3 (POSIX 2001) .

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

Большинство инструментов копирования (например, pax, rsync) ведут себя одинаково. Вы можете убедиться, что файл будет создан с разрешением по умолчанию, отделив источник от места назначения, например, с помощью cat <baz >foo/baz.

Жиль "ТАК - прекрати быть злым"
источник
Ну, это, по крайней мере, объясняет мотивацию для этого. (Странно, однако, что право собственности группы может измениться на «felles», что дает потенциально большему количеству людей доступ к файлу для чтения.)
2010 г.,
3

Ну, трехлетний и еще вопрос, но все еще актуален. Для будущих читателей я хочу добавить, что ожидается, что команды mv, cp не следуют за ACL каталога назначения. Ответ Жиля все в порядке, но последнее предложение. Лучший способ применить ACL-адресат к скопированному / перемещенному файлу - упомянутый здесь способ:

http://www.commandlinefu.com/commands/view/4281/copy-acl-of-one-file-to-another-using-getfacl-and-setfacl

В случае, если ссылка не работает в будущем, я вставляю содержимое здесь:

getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>

скопировать ACL одного файла в другой, используя getfacl и setfacl

ВНИМАНИЕ: Существующий ACL будет потерян.

biocyberman
источник
1

У меня была похожая проблема с rsynced файлами, в которых отсутствовали правильные списки ACL по умолчанию в целевом подкаталоге. Cp не имеет возможности устанавливать разрешения для цели. Но rsync использует этот --chmod=ugo=rwxфлаг. Смотрите мой ответ здесь .

Eric.chowanski
источник
0

Вам нужно использовать -pили --preserveс cp.

От man 5 acl:

ИЗМЕНЕНИЯ В ФАЙЛАХ

 On a system that supports ACLs, the file utilities ls(1), cp(1), and
 mv(1) change their behavior in the following way:

 ·   For files that have a default ACL or an access ACL that contains more
     than the three required ACL entries, the ls(1) utility in the long
     form produced by ls -l displays a plus sign (+) after the permission
     string.

 ·   If the -p flag is specified, the cp(1) utility also preserves ACLs.
     If this is not possible, a warning is produced.

 ·     The mv(1) utility always preserves ACLs. If this is not possible, a
     warning is produced.

 The effect of the chmod(1) utility, and of the chmod(2) system call, on
 the access ACL is described in CORRESPONDENCE BETWEEN ACL ENTRIES AND
 FILE PERMISSION BITS.
Приостановлено до дальнейшего уведомления.
источник
1
Не совсем. Он хочет, чтобы файл имел те же права, что и целевая папка.
luckytaxi
0

Списки ACL распространяются правильно, но маска по умолчанию кажется неправильной. Вы, вероятно, хотите, чтобы маска по умолчанию была rwX.

setfacl -dm m::rwX foo

Если это не сработает, пожалуйста, опубликуйте ACL для foo.

Райан Бэйр
источник
Это не сработало. ACL для foo (как до, так и после вашей команды): # file: foo # owner: bhm # group: felles # flags: -s- user :: rwx group :: rwx group: felles: rwx mask :: rwx other: : rx default: user :: rwx default: group :: rwx default: group: felles: rwx default: mask :: rwx default: other :: rx
bhm
-1

Монтируется ли ваша файловая система с включенной опцией «ACL»?

/dev/sda4        /wherefolderislocated         ext3        defaults,acl     1   2

Если нет, внесите изменения, затем перемонтируйте.

mount -o remount /wherefolderislocated
luckytaxi
источник
Да, он был смонтирован с опцией acl.
2010 года
-1

Из того, что я вижу, вы являетесь владельцем файлов (BHM) до и после cp. Как показывает список каталогов, владелец имеет права на чтение и запись!

Niko
источник
Возможно, мне было неясно: я хочу, чтобы группа («феллы») могла (читать и) записывать файл.
2010 г.