2:38 p.m.
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
3:49 p.m.
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.
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
3:56 p.m.
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
4 p.m.
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
4:27 p.m.
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(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
>> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:16 a.m.
The problem is that the WildFlySecurityManager is in the Core (used when you start it with
-secmgr argument), but I don't see a way how to configure permissions for it without
the subsystem.
For me it's fine to use the old-school policy file with WF Core - I've tried it
... without success.
-- josef
----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
To: "Brian Stansberry" <brian.stansberry(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Wednesday, August 26, 2015 4:00:16 PM
Subject: Re: [wildfly-dev] Permissions in WildFly Core
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
1:08 p.m.
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
3:31 p.m.
The security manager subsystem should definitely be in core. It only
has a casual association with Java EE 7 and there's really no practical
way to run under a security manager without it.
On 08/27/2015 06:08 AM, Jason T. Greene 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
<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
> >>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
--
- DML
9:54 a.m.
Hi,
thanks for all your comments.
I've created a new JIRA [1] to cover moving the security-manager subsystem from
WildFly to the Core.
[1] https://issues.jboss.org/browse/WFLY-5227
Regards,
-- josef
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Thursday, August 27, 2015 3:31:03 PM
Subject: Re: [wildfly-dev] Permissions in WildFly Core
The security manager subsystem should definitely be in core. It only
has a casual association with Java EE 7 and there's really no practical
way to run under a security manager without it.
On 08/27/2015 06:08 AM, Jason T. Greene 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
> <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
>> >>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
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:19 p.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
3:38 p.m.
Getting rid of the jboss metadata dependency is trivial. It just uses it
for a no-op impl of a simple interface, and then a few one line utility
methods to generate exception messages.
On 8/28/15 5:19 AM, Tomaž Cerar wrote:
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 <mailto:jason.greene@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
<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
> >> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3415
days inactive
3417
days old
10 comments
5 participants
participants (5)
-
Brian Stansberry -
David M. Lloyd -
Jason T. Greene -
Josef Cacek -
Tomaž Cerar