我们在spring安全性中遇到了意外的缺少按位权限检查的情况。我们想确认这是否是预期的行为，如果是，历史和/或理由是什么。
我们使用的是grails插件spring-security-acl-1.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
然而，默认的授予策略仍然只检查确切的掩码。因此：
- 为什么默认授予策略不检查按位掩码？如果不应该检查累积权限，那么累积权限有什么意义
- 处理按位权限的首选方法是什么？我们是错误地配置权限，还是应该只想实现按位权限检查（在这种情况下，首选的方法是什么）
感谢您的解释或指导。
当我创建插件时，这让我非常惊讶。假装使用位屏蔽，最终将自己的权限限制在32个似乎很奇怪（尽管这对大多数应用程序来说应该足够了）。参见本·亚历克斯的解释：https://jira.spring.io/browse/SEC-1140