我们有一个Mac App Store应用程序,需要访问Accessibility API。从10.9 Mavericks开始,对于要使用Accessibility API的应用程序都有一个系统白名单(系统偏好设置→安全和隐私→可访问性)。
在测试我们应用程序的更新时,我们注意到从旧版本升级后,系统会告诉我们,即使我们的应用程序位于Windows上,我们也无权使用Accessibility API(AXIsProcessTrustedWithOptions
返回NO
)。白名单,并选中该复选框。取消选中并重新检查权限后,一切正常。
显然,这对于我们来说是 Not Acceptable 升级方案,尤其是由于可访问性白名单已深深地埋在“系统偏好设置”中,因此无法通过代码进行访问。
这是系统错误吗?有已知的解决方法吗?我们将接受在大的更新后不得不重新检查“可访问性”权限的问题–它只是将您的用户导航到“系统偏好设置”,只是为了查看已选中的复选框,而该功能无法正常工作。
更新:
在首次升级后启动期间,系统在控制台中发出以下提示:
16/03/15 06:47:10,343 tccd[190]: Unable to verify code signing identity of com.company.app: code failed to satisfy specified code requirement(s)
16/03/15 06:47:10,350 universalAccessAuthWarn[401]: AccessibilityAPI: pid 471, is not allowed to access the accessibility API. Path: /path/to/app
奇怪的是,一旦取消选中并重新选中了可访问性白名单上的权限复选框,即使二进制文件是相同的,在随后的启动过程中控制台中也没有任何错误。
我已经深入了解了实现访问白名单(
/Library/Application Support/com.apple.TCC/TCC.db
)的SQLite数据库。 access
表包含一个csreq
列,看起来像一些应用程序指纹/哈希值blob:$ sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select client, quote(csreq) from access'
com.apple.dt.Xcode|X'…'
com.apple.AccessibilityInspector|X'…'
com.ourcompany.app|X'…'
(引用的哈希值替换为“...”。)
现在,如果我安装了较旧版本的应用程序并运行它,则系统将计算出一个哈希值并将其存储在
csreq
列中。如果我执行新应用程序版本的全新安装,则会得到不同的哈希值。当我安装旧版本然后删除它时,该列仍包含旧版本的哈希。这可能是问题的根源吗?因为当我在更新应用程序之前将列设置为
NULL
时,一切正常。计算出一个新的哈希值后,可访问性API检查将按应有的方式返回YES
。GitHub上的Same issue in a different app。
最佳答案
有一种叫做指定要求的内容(请参阅Code Signing Guide)。粗略地说,这是系统用来确定两个应用程序包是否代表同一应用程序的一组标准(从安全角度而言)。可以使用codesign -dvv --req - YourApp.app
命令显示指定的需求。在我们的情况下,指定的要求检查失败,因为较旧的应用程序版本使用的证书与开发版本的证书不同。
换句话说,当尝试用开发版本替换Mac App Store版本时,由于证书不匹配,安全检查将失败,您将不得不重新检查某些应用程序权限。据我所知,当您通过Mac App Store分发并安装相同的版本时,不会发生这种情况。