[jira] [Commented] (FELIX-5979) Felix Security: Support custom permissions that imply other permissions

["Karl Pauls (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681950#comment-16681950 ] 

Karl Pauls commented on FELIX-5979:
-----------------------------------

Well, I'm not against experimenting with it a bit. The thing is, IIRC, implies alone can not be the deciding factor as it is only supposed to check the actions of a given permission (not the permission type itself) - hence, the name check. However, I guess it might be ok to allow subclasses to imply parent classes. 

Unfortunately, the code for that would be a little work as the caching and the current lookup would need to be change to work with subclasses. If you find the time to create a patch as a proposal I'm willing to look at it...

> Felix Security: Support custom permissions that imply other permissions
> -----------------------------------------------------------------------
>
>                 Key: FELIX-5979
>                 URL: https://issues.apache.org/jira/browse/FELIX-5979
>             Project: Felix
>          Issue Type: Improvement
>          Components: Framework Security
>            Reporter: Timothy Carroll
>            Priority: Major
>
> My company is trying to use Framework Security to allow customers to upload custom java plugins to our platform without a security review of the java code. Among the set of permissions we're applying is denying access to all IP addresses in a 16 bit subnet. This cannot be accomplished through the standard socket or URL permissions.
> Our hope was to write our own {{SubnetSocketPermission}} that can imply SocketPermissions, but we found that the framework does not support this. In the {{Permissions.implies}} method in {{v2.4.0}}, you can find this code:
> {code}
>                 collection = target.newPermissionCollection();
>                 if (collection == null)
>                 {
>                     collection = new DefaultPermissionCollection();
>                 }
>                 for (int i = 0; i < m_permissionInfos.length; i++)
>                 {
>                     PermissionInfo permissionInfo = m_permissionInfos[i];
>                     String infoType = permissionInfo.getType();
>                     String permissionType = targetClass.getName();
>                     if (infoType.equals(permissionType))
>                     {
>                         Permission permission = createPermission(
>                             permissionInfo, targetClass);
>                         if (permission != null)
>                         {
>                             collection.add(permission);
>                         }
>                     }
>                 }
> {code}
> It has two pieces that prevent us from accomplishing our goal:
> # The only way to get your permission added to the {{PermisisonCollection}} that is checked is to have the exact same class name as the permission in question
> # The target permission's {{PermissionCollection}} is used to check permissions, and the {{SocketPermissionCollection}} class doesn't even use the {{SocketPermission.implies}} method
> Was this use case purposefully not supported or is it simply a matter of working through the most efficient way to support it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)