☰

当为正确的用户设置 ACL 时，为什么 rsync 在 Mac OS X 上会出现“权限被拒绝”错误？

tag-icon • tag-icon rsync access-control-list osx-snow-leopard
当为正确的用户设置 ACL 时，为什么 rsync 在 Mac OS X 上会出现“权限被拒绝”错误？

我正在从一个旧工具过渡到 Mac OS X 10.6 Snow Leopard Serverrsync上托管的 Web 表单（完全位于防火墙后面，具有多个身份验证层，这不是借口）启动（使用 SSH 主机密钥从本地路径复制到远程路径）。为了解决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二进制文件并设置了执行时设置用户ID位时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 有什么问题？

答案1

在 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，看起来可能是缺少“搜索”访问权限导致了失败（也许是其他原因，尽管这些似乎只与扩展属性有关）。

答案2

如果你将文件传输到远程存储（如 FreeNAS 等）——不要忘记设置正确的规则。不仅要设置所有者，但包括此所有者读写列表还。

freeNAS 示例

我对此很着迷。

相关内容