[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato commented on WFCORE-2061:
----------------------------------------
The direct cause is clear: After it's logged in with {{LoginContext}}, the subject is only attached with simple principals. However, wildfly-core-security expects a {{RealmUser}} principal in it and thus fails to resolve its name with the subject when role mapping is executed. So if you manually add a {{RealmUser}} to the subject after login, then the issue doesn't happen:
{code:java}
subject.getPrincipals().add(new RealmUser("admin"));
{code}
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Kabir Khan
> Priority: Critical
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato updated WFCORE-2061:
-----------------------------------
Steps to Reproduce:
# Copy the attached {{standalone.xml}} to {{$WFLY_HOME/standalone/configuration/}}
# Add user {{admin}}:
{code}
$ ./bin/add-user.sh -u admin -p p@ssw0rd
{code}
# Start WildFly 10.1.0.Final:
{code}
$ ./bin/standalone.sh
{code}
# Run the attached reproducer {{wildfly-jmx-auth}}:
{code}
$ mvn clean test
{code}
# You'll see the test fails showing
{quote}javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access{quote}
in the server log
was:
# Copy the attached {{standalone.xml}} to {{$WFLY_HOME/standalone/configuration/}}
# Add user {{admin}}:
{code}
$ ./bin/add-user.sh -u admin -p p@ssw0rd
{code}
# Start WildFly:
{code}
$ ./bin/standalone.sh
{code}
# Run the attached reproducer {{wildfly-jmx-auth}}:
{code}
$ mvn clean test
{code}
# You'll see the test fails showing
{quote}javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access{quote}
in the server log
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Kabir Khan
> Priority: Critical
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato updated WFCORE-2061:
-----------------------------------
Attachment: wildfly-jmx-auth.zip
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Kabir Khan
> Priority: Critical
> Attachments: standalone.xml, wildfly-jmx-auth.zip
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2061?page=com.atlassian.jira.plugi... ]
Tadayoshi Sato updated WFCORE-2061:
-----------------------------------
Attachment: standalone.xml
> JMX access unauthorized after RBAC enabled
> ------------------------------------------
>
> Key: WFCORE-2061
> URL: https://issues.jboss.org/browse/WFCORE-2061
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Security
> Affects Versions: 2.2.0.Final
> Reporter: Tadayoshi Sato
> Assignee: Kabir Khan
> Priority: Critical
> Attachments: standalone.xml
>
>
> After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
> {code:java}
> MBeanServer mBeanServer = ...
> Subject subject = new Subject();
> // Login
> new LoginContext("test-domain", subject, callbacks -> { ... }).login();
> // Access to JMX
> Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
> mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
> return null;
> });
> {code}
> RBAC and role-mapping are enabled in {{standalone.xml}} like this:
> {code:xml}
> <access-control provider="rbac">
> <role-mapping>
> <role name="SuperUser">
> <include>
> <user name="$local"/>
> <user name="admin"/>
> </include>
> </role>
> </role-mapping>
> </access-control>
> [...]
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> [...]
> <security-domain name="test-domain" cache-type="default">
> <authentication>
> <login-module code="RealmDirect" flag="required">
> <module-option name="realm" value="ManagementRealm"/>
> </login-module>
> </authentication>
> </security-domain>
> {code}
> The code gets this error in the server log:
> {code}
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
> at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
> at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
> at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2061) JMX access unauthorized after RBAC enabled
by Tadayoshi Sato (JIRA)
Tadayoshi Sato created WFCORE-2061:
--------------------------------------
Summary: JMX access unauthorized after RBAC enabled
Key: WFCORE-2061
URL: https://issues.jboss.org/browse/WFCORE-2061
Project: WildFly Core
Issue Type: Bug
Components: JMX, Security
Affects Versions: 2.2.0.Final
Reporter: Tadayoshi Sato
Assignee: Kabir Khan
Priority: Critical
Attachments: standalone.xml
After RBAC is enabled, even a user ({{"admin"}}) with {{SuperUser}} role fails to get authorized access to JMX with the following code:
{code:java}
MBeanServer mBeanServer = ...
Subject subject = new Subject();
// Login
new LoginContext("test-domain", subject, callbacks -> { ... }).login();
// Access to JMX
Subject.doAs(subject, (PrivilegedAction<Object>) () -> {
mBeanServer.getAttribute(new ObjectName("java.lang:type=Memory"), "HeapMemoryUsage"));
return null;
});
{code}
RBAC and role-mapping are enabled in {{standalone.xml}} like this:
{code:xml}
<access-control provider="rbac">
<role-mapping>
<role name="SuperUser">
<include>
<user name="$local"/>
<user name="admin"/>
</include>
</role>
</role-mapping>
</access-control>
[...]
<subsystem xmlns="urn:jboss:domain:security:1.2">
<security-domains>
[...]
<security-domain name="test-domain" cache-type="default">
<authentication>
<login-module code="RealmDirect" flag="required">
<module-option name="realm" value="ManagementRealm"/>
</login-module>
</authentication>
</security-domain>
{code}
The code gets this error in the server log:
{code}
javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1203)
at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:387)
at com.redhat.issues.wildfly.JmxServlet.readMBeanAttribute(JmxServlet.java:87)
at com.redhat.issues.wildfly.JmxServlet.lambda$process$0(JmxServlet.java:53)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.redhat.issues.wildfly.JmxServlet.process(JmxServlet.java:52)
at com.redhat.issues.wildfly.JmxServlet.doGet(JmxServlet.java:44)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5227:
----------------------------------------
Re: the GAV, yeah, it's probably easier to deal with it in on go. Changing it later will involve yet another dance of coordinated changes.
I just looked and the only uses of this artifact are in the servlet-feature-pack, which would go away regardless as the module will instead be packaged up in core's core-feature-pack. So really the only people who might care about this GAV are 1) layered products (highly doubtful) or 2) Swarm (reasonably likely as they slice and dice the server.)
I'll ping [~hbraun] to see if changes this GAV matters to them, and if it does whether maintaining an empty pom with the old GAV is helpful.
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 6:47 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remote add wildfly <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integration project, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
- jbossas/jboss-eap7 7.x branch PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remote add wildfly <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
- jbossas/jboss-eap7 7.x branch PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5227) Move security-manager subsystem from WildFly to WildFly Core
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-5227?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFLY-5227 at 11/29/16 6:43 PM:
-----------------------------------------------------------
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remote add wildfly <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
- jbossas/jboss-eap7 7.x branch PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
was (Author: luck3y):
After some digging, here are the steps that I propose:
(1) Checkout wildfly
- branch for this change $ git branch -b security-manager
- git filter-branch --subdirectory-filter security-manager -- --all
- This will result in security-manager being moved to the root of the wildfly project, so move it back to a subdir, preserving history:
git filter-branch --prune-empty --tree-filter '
if [[ ! -e security-manager ]]; then
mkdir -p security-manager
git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files security-manager
fi'
- git rebase -i and remove commits up to 'de72c28 WFLY-401 Add the security manager subsystem', and any "Release xxx," and "Next is yyy, " commits.
- There are a couple of trivial conflicts that need to be resolved in the rebase, resolve and rebase --continue.
(2) wildfly-core
- git checkout -b security-manager
- git remote add wildfly <location of wildfly above>
- git fetch wildfly security-manager
- git pull wildfly security-manager
- enable the security-manager subsystem in core, and build.[1]
- commit this change & push to GH
(3) The wildfly security manager branch above may now be deleted
- create a new branch, and remove the security-manager, push branch to GH
(4) Perform CI testing using the wildfly integrations tests, pointing to both branches from above.
(5) Once testing etc is successful, we'll need to perform the change as follows:
- wildfly-core PR should add and enable the security-manager
- wildfly PR will remove the security manager and upgrade wildfly-core to the newer version.
[1] still needs some documentation.
Example cleaned up diff here: https://github.com/wildfly/wildfly-core/compare/master...luck3y:security-...
> Move security-manager subsystem from WildFly to WildFly Core
> ------------------------------------------------------------
>
> Key: WFLY-5227
> URL: https://issues.jboss.org/browse/WFLY-5227
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Reporter: Josef Cacek
> Assignee: Ken Wills
> Priority: Critical
>
> It's not possible to define security permissions in WildFly Core without {{security-manager}} subsystem. Therefore the subsystem should be moved from WildFly to the Core.
> More details in the [Permissions in WildFly Core|http://lists.jboss.org/pipermail/wildfly-dev/2015-August/thread.html...] thread on {{wildfly-dev}} mailing list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months