为什么在为正确的用户设置ACL时,rsync会在Mac OS X上获得“权限被拒绝”错误?

我正在从一个旧的工具,通过一个Web表单(完全位于防火墙之后,有多个authentication层,这不是借口)启动一个rsync (从本地path复制到远程path)在Mac OS X 10.6 Snow Leopard服务器上。 为了解决rsync_www运行这个事实,但这些文件是由_www用户拥有的(加上SSH用户密钥是针对某个用户的),原作者制作了rsync二进制文件副本,并且拥有4755& someuser作为所有者的权限所以,运行rsync副本的任何人都以someuser用户身份运行)。 一个肮脏的黑客,当然,但它的工作原理(它是在Mac OS X甚至支持ACL之前编写的,所以它至less可以理解,尽pipe从安全angular度来看它仍然很残酷)。

作为离开这个解决scheme的第一步,我已经将这些文件的权限从777(由_www用户拥有)更改为755(仍然由_www用户拥有),然后设置ACL的访问权限以便对这些文件具有完全访问权限如下:

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

不幸的是,虽然仍然使用相同的rsync二进制文件与为someuser用户设置的set-user-ID-on-execution位, 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有什么问题?

在Server Admin.app中,我启用了“在用户和组浏览器中显示系统帐户”首选项,然后进入文件共享并浏览到/path/to/directory/ (w /“Volumes”&“Browse”工具栏)我为'_www'用户添加了一个“自定义”ACL(没有“pipe理”,但是都是“读取”,“写入”和“适用于”)并传播了权限。

运行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,看起来可能是导致失败的缺失“search”访问(也许其他一些访问,尽pipe这些访问似乎只与扩展属性有关)。

如果您将文件传输到远程存储(如FreeNAS等),请不要忘记设置正确的规则。 不仅设置所有者 ,而且还包括这个ownerto 读写列表

freeNAS例子

我迷上了这个。