Re: [wildfly-dev] Permissions in WildFly Core

That might actually be ok, since we aren't talking about a Java API, and there are no reps on other specs. However I agree that is wierd. Alternatively we could add different format/schema but I suspect it would look just like permissions.xml. On Aug 26, 2015, at 9:00 AM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com>> 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(a)redhat.com <mailto:brian.stansberry@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 > &gt;&gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev