5:19 a.m.
If we could make it support jboss-permissions.xml without using jboss
metadata
that would solve the extra dependency and not much increase in distro size
On Thu, Aug 27, 2015 at 1:08 PM, Jason T. Greene <jason.greene(a)redhat.com>
wrote:
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> 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> 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(a)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
> 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