[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ]
Peter Palaga edited comment on WFLY-7412 at 12/14/16 10:51 AM:
---------------------------------------------------------------
To make sure that this issue was fixed I created a simple test project: https://github.com/ppalaga/WFLY-7412
What it does:
* It builds WildFly from source using srcdeps
* It configures a test instance with a security-domain with two custom login modules that live in two independent JBoss Modules
* Runs some tests that invoke both login modules.
Indeed, it proves that the fix works.
It would certainly be good to have such a test in the WildFly testsuite. I'd do it straight away, but I was not able to find any similar integration test in the WF code base that would run some management commands and add custom JBoss modules to the test instance. I am kinda hesitant to push my solution based on maven plugins there, because it looks too different from the usual Arquillian way of writing itests.
Could perhaps anybody point me to an arquillian test that runs management commands and installs custom JBoss modules?
was (Author: ppalaga):
To make sure that this issue was fixed I created a simple test project: https://github.com/ppalaga/WFLY-7412
What it does:
* It builds WildFly from source using srcdeps
* It configures a test instance with a security-domain with two custom login modules that live in two independent JBoss Modules
* Runs some tests that invoke both login modules.
Indeed, it proves that the fix works.
I would certainly be good to have such a test in the WildFly testsuite. I'd do it straight away, but I was not able to find any similar integration test in the WF code base that would run some management commands and add custom JBoss modules to the test instance. I am kinda hesitant to push my solution based on maven plugins there, because it looks too different from the usual Arquillian way of writing itests.
Could perhaps anybody point me to an arquillian test that runs management commands and installs custom JBoss modules?
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: WFLY-7412
> URL: https://issues.jboss.org/browse/WFLY-7412
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Fix For: 11.0.0.Alpha1
>
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Ken Wills reassigned WFCORE-1307:
---------------------------------
Assignee: Ken Wills
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Ken Wills
> Fix For: 3.0.0.CR1
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ]
Peter Palaga commented on WFLY-7412:
------------------------------------
To make sure that this issue was fixed I created a simple test project: https://github.com/ppalaga/WFLY-7412
What it does:
* It builds WildFly from source using srcdeps
* It configures a test instance with a security-domain with two custom login modules that live in two independent JBoss Modules
* Runs some tests that invoke both login modules.
Indeed, it proves that the fix works.
I would certainly be good to have such a test in the WildFly testsuite. I'd do it straight away, but I was not able to find any similar integration test in the WF code base that would run some management commands and add custom JBoss modules to the test instance. I am kinda hesitant to push my solution based on maven plugins there, because it looks too different from the usual Arquillian way of writing itests.
Could perhaps anybody point me to an arquillian test that runs management commands and installs custom JBoss modules?
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: WFLY-7412
> URL: https://issues.jboss.org/browse/WFLY-7412
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Fix For: 11.0.0.Alpha1
>
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-832) Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-832?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek updated ELY-832:
----------------------------
Description:
Coverity static-analysis scan found possible method call on null object in {{CredentialStoreCredentialSource.getCredential()}}
https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
The problematic piece of code is:
{code:java}
credential = credentialStore.retrieve(alias, credentialType);
return credential.castAs(credentialType, algorithmName, parameterSpec);
{code}
The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
{code:java}
//...
final TopEntry topEntry = cache.get(credentialAlias);
if (topEntry == null) {
return null;
}
//...
{code}
was:
Coverity static-analysis scan found possible method call on null object in {{CredentialStoreCredentialSource.getCredential(Class, String, AlgorithmParameterSpec)}}
https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
The problematic piece of code is:
{code:java}
credential = credentialStore.retrieve(alias, credentialType);
return credential.castAs(credentialType, algorithmName, parameterSpec);
{code}
The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
{code:java}
//...
final TopEntry topEntry = cache.get(credentialAlias);
if (topEntry == null) {
return null;
}
//...
{code}
> Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-832
> URL: https://issues.jboss.org/browse/ELY-832
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Labels: static_analysis
>
> Coverity static-analysis scan found possible method call on null object in {{CredentialStoreCredentialSource.getCredential()}}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
> The problematic piece of code is:
> {code:java}
> credential = credentialStore.retrieve(alias, credentialType);
> return credential.castAs(credentialType, algorithmName, parameterSpec);
> {code}
> The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
> {code:java}
> //...
> final TopEntry topEntry = cache.get(credentialAlias);
> if (topEntry == null) {
> return null;
> }
> //...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-832) Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/ELY-832?page=com.atlassian.jira.plugin.sy... ]
Josef Cacek updated ELY-832:
----------------------------
Description:
Coverity static-analysis scan found possible method call on null object in {{CredentialStoreCredentialSource.getCredential(Class, String, AlgorithmParameterSpec)}}
https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
The problematic piece of code is:
{code:java}
credential = credentialStore.retrieve(alias, credentialType);
return credential.castAs(credentialType, algorithmName, parameterSpec);
{code}
The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
{code:java}
//...
final TopEntry topEntry = cache.get(credentialAlias);
if (topEntry == null) {
return null;
}
//...
{code}
was:
Coverity static-analysis scan found possible method call on null object in {{org.wildfly.security.credential.source.CredentialStoreCredentialSource.getCredential(java.lang.Class, java.lang.String, java.security.spec.AlgorithmParameterSpec)}}
https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
The problematic piece of code is:
{code:java}
credential = credentialStore.retrieve(alias, credentialType);
return credential.castAs(credentialType, algorithmName, parameterSpec);
{code}
The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
{code:java}
//...
final TopEntry topEntry = cache.get(credentialAlias);
if (topEntry == null) {
return null;
}
//...
{code}
> Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-832
> URL: https://issues.jboss.org/browse/ELY-832
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Labels: static_analysis
>
> Coverity static-analysis scan found possible method call on null object in {{CredentialStoreCredentialSource.getCredential(Class, String, AlgorithmParameterSpec)}}
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
> The problematic piece of code is:
> {code:java}
> credential = credentialStore.retrieve(alias, credentialType);
> return credential.castAs(credentialType, algorithmName, parameterSpec);
> {code}
> The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
> {code:java}
> //...
> final TopEntry topEntry = cache.get(credentialAlias);
> if (topEntry == null) {
> return null;
> }
> //...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-832) Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
by Josef Cacek (JIRA)
Josef Cacek created ELY-832:
-------------------------------
Summary: Coverity static analysis: Dereference null return value in CredentialStoreCredentialSource (Elytron)
Key: ELY-832
URL: https://issues.jboss.org/browse/ELY-832
Project: WildFly Elytron
Issue Type: Bug
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Coverity static-analysis scan found possible method call on null object in {{org.wildfly.security.credential.source.CredentialStoreCredentialSource.getCredential(java.lang.Class, java.lang.String, java.security.spec.AlgorithmParameterSpec)}}
https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=68037...
The problematic piece of code is:
{code:java}
credential = credentialStore.retrieve(alias, credentialType);
return credential.castAs(credentialType, algorithmName, parameterSpec);
{code}
The {{retrieve()}} method may return {{null}} in some cases as can be seen in {{KeyStoreCredentialStore}} class:
{code:java}
//...
final TopEntry topEntry = cache.get(credentialAlias);
if (topEntry == null) {
return null;
}
//...
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months