[wildfly-dev] Permissions in WildFly Core

Brian Stansberry brian.stansberry at redhat.com
Wed Aug 26 10:27:00 EDT 2015


Right. I've been looking into the size impacts, so since those appear to 
be solvable, this discussion can just focus on whether it belongs.

On 8/26/15 9:00 AM, Tomaž Cerar wrote:
> Also AFAIR, security manager subsystem implements EE7 security
> manager(permissions.xml) support.
> and as such doesn't belong to core.
>
> On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     On 8/26/15 8:49 AM, Brian Stansberry wrote:
>     > Just some data, as I know distribution size is a significant factor in
>     > deciding what goes into WildFly Core:
>     >
>     > The org.wildfly.extension.security.manager module itself is 45KB
>     > unzipped, so not much of a concern.
>     >
>     > However, it depends on org.jboss.metadata.common, which is 475KB and
>     > isn't itself present in WildFly Core.
>
>     The requirement for org.jboss.metadata.common looks pretty simple to
>     eliminate. It's just using a bit of what looks like easily duplicated
>     utility code.
>
>      >
>      > All its other deps are present in WildFly Core.
>      >
>      > On 8/26/15 7:38 AM, Josef Cacek wrote:
>      >> Hi *,
>      >>
>      >> Is there a way how to configure Java security permissions in
>     WildFly Core?
>      >> If not, is there any reason why not to move the
>     wildfly-security-manager from WildFly into WildFly Core?
>      >>
>      >> I'm investigating failing tests in WildFly Core testsuite
>     ([1],[2]) when security manager is enabled.
>      >>
>      >> The problem is, security manager is in place and I'm not able to
>     define permissions for deployments
>      >> - using policy file (configured by java.security.policy system
>     property) doesn't work for me;
>      >> - putting META-INF/permissions.xml into deployments doesn't help
>     because PermissionsParseProcessor deployment processor is part of
>     wildfly-security-manager (i.e. not in Core) and it is only activated
>     when security-manager subsystem is present.
>      >>
>      >> So the tests fail because of AccessControlExceptions on the
>     server side.
>      >>
>      >> Any thoughts?
>      >>
>      >> As a workaround we can run the Core testsuite against full
>     WildFly and use either in-deployment permissions.xml or configure
>     permissions in subsystem [3] - but both ways have some disadvantages.
>      >> We either have to put "unnecessary" permissions.xml in WFCORE
>     deployments or we have to use too wide minimum-permissions in
>     security-manager subsystem configuration.
>      >>
>      >> [1] https://issues.jboss.org/browse/WFCORE-846
>      >> [2] https://issues.jboss.org/browse/JBEAP-526
>      >> [3]
>     /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions,
>     value=[{class=java.security.AllPermission}])")
>      >>
>      >> Thanks,
>      >>
>      >> -- Josef Cacek
>      >> _______________________________________________
>      >> wildfly-dev mailing list
>      >> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>
>      >
>      >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list