Я ухожу от старого инструмента, который запускает 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, можно сделать вывод, что причиной сбоев был, вероятно, отсутствующий доступ для «поиска» (возможно, некоторые другие, хотя они, похоже, связаны только с расширенными атрибутами).