Обычный способ создания каталога для совместного использования файлов в группе:
$ 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--
Почему это происходит и есть ли способ обойти это?
(Переезд файл в каталоге не учитывает ни списки управления доступом, ни групповое владение, но я могу понять, почему: вы можете не захотеть, чтобы права доступа к файлу менялись просто потому, что вы изменили его имя.)
Если cp создает файл назначения, он копирует разрешения исходного файла, за исключением битов, установленных в umask. Это стандартное поведение (см., Например, шаг 3.b в Спецификация Single Unix v3 (POSIX 2001).
Почему cp была разработана таким образом? Потому что есть много случаев, когда такое поведение желательно, например, сохранение конфиденциальности файла, когда исходные разрешения являются ограничительными, и сохранение исполняемости почти всегда является правильным решением. Однако, к сожалению, даже GNU cp не имеет возможности отключить это поведение.
Большинство инструментов копирования (например, pax, rsync) ведут себя одинаково. Вы можете гарантировать, что файл будет создан с разрешением по умолчанию, отделив источник от места назначения, например, с помощью cat <baz >foo/baz.
Ну, трехлетний и еще вопрос, но все еще актуальный. Для будущих читателей я хочу добавить, что ожидается, что команды mv, cp не следуют за ACL каталога назначения. Ответ Жиля хорош, кроме последнего предложения. Лучший способ применить ACL назначения к скопированному / перемещенному файлу - это способ, упомянутый здесь:
Если в будущем ссылка не работает, я вставляю содержимое сюда:
getfacl <file-with-acl> | setfacl -f - <file-with-no-acl>
скопировать ACL одного файла в другой с помощью getfacl и setfacl
ВНИМАНИЕ: существующий ACL будет потерян.
У меня была аналогичная проблема с файлами rsynced, у которых отсутствовали правильные ACL по умолчанию в целевом подкаталоге. Cp не имеет возможности устанавливать разрешения для цели. Но rsync делает, используя --chmod=ugo=rwx флаг. Смотрите мой ответ Вот.
Вам нужно использовать -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.
Списки ACL распространяются правильно, но маска по умолчанию кажется неправильной. Вероятно, вы хотите, чтобы ваша маска по умолчанию была rwX.
setfacl -dm m::rwX foo
Если это не сработает, опубликуйте ACL для foo.
Ваша файловая система смонтирована с включенной опцией «ACL»?
/dev/sda4 /wherefolderislocated ext3 defaults,acl 1 2
Если нет, внесите изменения и перемонтируйте.
mount -o remount /wherefolderislocated
Насколько я понимаю, вы являетесь владельцем файлов (bhm) до и после cp. Как видно из списка каталогов, у владельца есть доступ для чтения и записи!