Значения по умолчанию ACL, не повиновавшись на копии по NFS

Я думаю, что ACLs эпизодически поддерживаются различными способами в NFS. См. эту статью о веб-сайте проекта NFS.

• http://www.linux-nfs.org/wiki/index.php/ACLs

Если бы это не проблема, то я был бы чрезвычайно подозрителен к cp. Я, кажется, вспоминаю Вопросы и ответы относительно команды cp не полностью копируя ACLs независимо от целенаправленный тип монтирования.

Я полагаю, что это было это названные Вопросы и ответы U&L: Используя setfacl, чтобы позволить элементам группы писать в любой файл в каталоге, который привел меня к этому SF названные Вопросы и ответы: Почему CP не уважает ACLs?.

Иронически наш собственный @Gilles записал ответ на том, что Вопросы и ответы SF, который объясняет почему cp не поддерживает распространение ACLs. Я полагаю, что это - все еще текущая ситуация!

выборка из ответа @Gilles

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

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

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

Пример

Я устанавливаю следующий файл, afile и добавил ACL к нему.

$ touch afile
$ setfacl -m user:sam:rwx,group:users:rwx afile

Мы теперь имеем:

$ getfacl afile 
# file: afile
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--

Когда я копирую эти файлы в долю NFSv3:

$ cp afile ~sam/
$ getfacl ~sam/afile 
getfacl: Removing leading '/' from absolute path names
# file: home/sam/afile
# owner: root
# group: root
user::rw-
group::rwx
other::r--

ACLs были потеряны. Попытка использовать --preserve переключатели к cp:

$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported

Включение ACL на NFS

Включение ACL на NFS монтируется, кажется, не имеют никакого эффекта также:

mulder:/export/r1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,acl,rsize=16384,wsize=16384,addr=192.168.1.1)

$ cp --preserve afile ~sam/
cp: preserving permissions for `/home/sam/afile': Operation not supported
cp: preserving ACL for `/home/sam/afile': Operation not supported

Тот же жесткий диск работал

Интересно --preserve переключатель действительно работал при копировании файла локально на том же подсоединенном внешнем диске EXT4.

$ cp --preserve afile afile2
$ getfacl afile2
# file: afile2
# owner: root
# group: root
user::rw-
user:sam:rwx
group::r--
group:users:rwx
mask::rwx
other::r--

Путь вперед?

В моем исследовании и экспериментировании казалось бы, что что-либо ниже NFSv4 не поддерживает ACLs. cp команда кажется способной сохранить ACLs, пока базовая файловая система поддерживает ACLs.

Я нашел эту статью: Проекты: Ссылочная Реализация Открытого исходного кода Версии 4 NFS, которая обсуждает использование ACLs в NFSv4. Таким образом, я ожидал бы, что копирование ACLs к доле NFSv4 могло бы быть возможным, я не полагаю, что это - возможное использование NFSv2 или NFSv3 все же.

Ссылки

• Списки управления доступом в Linux