Question

我们在Spring安全性中遇到意外缺少按位权限检查。我们想确认这是否是预期的行为，如果是，那么历史是什么和/或理由是什么。

我们正在使用grails插件spring-security-acl-1.1.1，它使用spring-security-acl 3.0.7.RELEASE。

我们正在尝试的方法涉及一个具有ACL的对象，以便aclUtilService.readAcl（obj）返回授予角色：

PrincipalSid[sampleuser]; permission: BasePermission[...........................A....=16]
GrantedAuthoritySid[ROLE_RWD]; permission: CumulativePermission[............................D.WR=11]
GrantedAuthoritySid[ROLE_RW]; permission: CumulativePermission[..............................WR=3]
GrantedAuthoritySid[ROLE_R]; permission: BasePermission[...............................R=1]

随后我们希望检查像WRITE这样的单一权限并让它返回true。但是，似乎不支持此功能。例如，对于具有在上述对象上定义的所有角色的用户，执行：

READ?: ${aclUtilService.hasPermission(springSecurityService.authentication, obj, BasePermission.READ)}
WRITE?: ${aclUtilService.hasPermission(springSecurityService.authentication, obj, BasePermission.WRITE)}
DELETE?: ${aclUtilService.hasPermission(springSecurityService.authentication, obj, BasePermission.DELETE)}
READ-WRITE?: ${aclUtilService.hasPermission(springSecurityService.authentication, obj, new BasePermission(BasePermission.READ.getMask() | BasePermission.WRITE.getMask()))}

返回输出：

READ?: true
WRITE?: false
DELETE?: false
READ-WRITE?: true

然而，我们希望所有这些都返回真实。查看源代码后，我们可以看到最终在AclImpl中检查了权限，其中包含行

if ((ace.getPermission().getMask() == p.getMask()) && ace.getSid().equals(sid)) {

这解释了为什么只有精确的面具匹配。

只更改了这一行，我们发现在spring-security-acl 3.1中，这个代码被重构，以允许定义权限授予策略 - https://jira.spring.io/browse/SEC-1166

但是，默认授权策略仍然只检查确切的掩码。所以：

为什么默认授权策略检查按位掩码？如果不应该检查CumulativePermission，有什么意义？
处理按位权限的首选方法是，我们是否正确配置权限，或者我们应该只是实现按位权限检查（在这种情况下，执行此操作的首选方法是什么）。

感谢您的任何解释或指导。

Answer 1

当我创建插件时，这让我很惊讶。假装使用位掩码似乎很奇怪，并且最终将自己限制为仅32个权限（尽管对于大多数应用程序来说应该足够了）。请参阅此JIRA，了解Ben Alex的解释：https://jira.spring.io/browse/SEC-1140

spring security acl不会比较按位权限

1 个答案: