Назад | Перейти на главную страницу

Почему rsync выдает ошибку «в разрешении отказано» в Mac OS X, если списки управления доступом заданы для правильного пользователя?

Я ухожу от старого инструмента, который запускает rsync (копирование с локального пути на удаленный с ключами хоста SSH) через веб-форму (полностью за межсетевым экраном с несколькими уровнями аутентификации, не то чтобы это оправдание), размещенную на сервере Mac OS X 10.6 Snow Leopard. Чтобы обойти тот факт, что rsync управляется _www, но файлы принадлежат someuser (плюс ключи хоста SSH предназначены для someuser) оригинальный автор сделал копию rsync двоичный с разрешениями 4755 и someuser как владелец (то есть любой, кто запускает эту копию rsync это работает как someuser пользователь). Грязный хакер, конечно, но он работает (и он был написан до того, как Mac OS X даже поддержала ACL, так что, по крайней мере, слегка понятно, хотя с точки зрения безопасности это все еще ужасно).

В качестве первого шага к отказу от этого решения я изменил права доступа к этим файлам с 777 (принадлежит someuser) до 755 (все еще принадлежит someuser), затем установите ACL для _www чтобы иметь полный доступ к этим файлам, а именно:

chmod -R +a "_www allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit" /path/to/directory

К сожалению, при использовании того же rsync двоичный с установленным битом set-user-ID-on-execution для someuser, rsync теперь выдает следующую ошибку:

building file list ... rsync: link_stat "/path/to/directory/subdir/." failed: Permission denied (13)
done

sent 332 bytes  received 20 bytes  704.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-30/rsync/main.c(717)

Если я проверю разрешения для этого каталога, они кажутся правильными:

$ ls -ael /path/to/directory/
total 0
drwxr-x---+  3 someuser  admin  102 Jun 23 19:00 .
 0: user:_www allow list,add_file,delete,add_subdirectory,file_inherit,directory_inherit
drwxr-xr-x   8 someuser  admin  272 Jun 23 18:57 ..
drwxr-xr-x+ 17 someuser  admin  578 Jun 23 17:15 subdir
 0: user:_www allow list,add_file,delete,add_subdirectory,file_inherit,directory_inherit

То же самое и с файлом в каталоге:

$ ls -ael /path/to/directory/subdir/file.txt 
-rwxr-xr-x+ 1 someuser  admin  107 Jun 23 17:15 subdir/file.txt
 0: user:_www allow read,write,delete,append

Что может вызвать эту ошибку разрешений, поскольку файлы все еще принадлежат пользователю, который rsync двоичные прогоны, плюс _www у пользователя должны быть полные ACL для каталога и файлов?

Обновить: Похоже, это проблема ACL, так как работает sudo -u _www ls -ael /path/to/directory/ также приводит к ошибкам "доступ запрещен":

ls: .: Permission denied
ls: ..: Permission denied
ls: subdir: Permission denied`

Итак, что не так с ACL, которые я установил?

Если вы переносите файлы в удаленное хранилище (например, FreeNAS и т. Д.) - не забудьте установить правильные правила. Не только набор владелец, но включите этого владельца в список для чтения и записи также.

Я подсел на это.

В Server Admin.app я включил параметр «Показывать системные учетные записи в браузере пользователей и групп», затем перешел в раздел «Общий доступ к файлам» и перешел к /path/to/directory/ (с выбранными на панели инструментов «Тома» и «Обзор») Я добавил «Пользовательский» ACL (без «Администрирования», но все «Чтение», «Запись» и «Применимо к») для пользователя '_www' и распространил разрешения.

Это привело к следующему при запуске ls как пользователь _www:

$ sudo -u _www ls -ale /path/to/directory
total 0
drwxr-x---+  3 someuser  admin  102 Jun 23 19:00 .
 0: user:_www allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit
drwxr-xr-x   8 someuser  admin  272 Jun 23 18:57 ..
drwxr-xr-x+ 17 someuser  admin  578 Jun 23 17:15 subdir
 0: user:_www inherited allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit

Итак, проблема решена. Глядя на заданные списки ACL, можно сделать вывод, что причиной сбоев был, вероятно, отсутствующий доступ для «поиска» (возможно, некоторые другие, хотя они, похоже, связаны только с расширенными атрибутами).