[JBoss JIRA] (ELY-1238) Elytron client, wildfly-config.xml, User is not able to use credential-store-reference with clear-text password to access credential store. Store name and alias must be incorrectly defined.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1238:
---------------------------------
Summary: Elytron client, wildfly-config.xml, User is not able to use credential-store-reference with clear-text password to access credential store. Store name and alias must be incorrectly defined.
Key: ELY-1238
URL: https://issues.jboss.org/browse/ELY-1238
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Blocker
Elytron client, wildfly-config.xml, User is not able to use credential-store-reference with clear-text password to access credential store. Store name and alias must be incorrectly defined.
There must work these two scenarious:
* User uses only clear-text password <credential-store-reference clear-text="pass123"/>
* User uses password obtained from another credential store <credential-store-reference store="CS_STORE_NAME" alias="pwd"/> and both "store" and "alias" must be defined.
I see problem in ElytronXmlParser [1], where is always used "storeName" and then "alias" to create new CredentialStoreCredentialSource(credentialStore, alias);
*How to reproduce*
* Please use files which are attached
* set right path to cs.jceks in wildfly-config.xml
* run EAP server
* run client
{code}
[hsvabek@dhcp-10-40-5-166 bin]$ ./jboss-cli.sh -c -Dwildfly.config.url=wildfly-config.xml
java.lang.ExceptionInInitializerError: org.wildfly.client.config.ConfigXMLParseException: ELY09503: Credential store name "null" not defined
at file:/home/hsvabek/securityworkspace/VERIFICATION/2017_06_08_wfly-config.xml/jboss-eap-7.1/bin/wildfly-config.xml:9:4: ELY09503: Credential store name "null" not defined
at file:/home/hsvabek/securityworkspace/VERIFICATION/2017_06_08_wfly-config.xml/jboss-eap-7.1/bin/wildfly-config.xml:9:4
{code}
When you set correct store to credential-store-reference, then you get error about "alias is required..."
[1] https://github.com/wildfly-security/wildfly-elytron/blob/1.1.0.Beta47/src...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2936) CLI parse blank string in command as undefined
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2936?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-2936:
--------------------------------------------
Assignee: Jean-Francois Denise
> CLI parse blank string in command as undefined
> ----------------------------------------------
>
> Key: WFCORE-2936
> URL: https://issues.jboss.org/browse/WFCORE-2936
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Beta25
> Reporter: Jan Kalina
> Assignee: Jean-Francois Denise
>
> CLI parse following command:
> {code}
> /subsystem=elytron/constant-permission-mapper=test2:add(permissions=[{class-name="abc",action="",target-name=""}])
> {code}
> as:
> {code}
> {
> "address" => [
> ("subsystem" => "elytron"),
> ("constant-permission-mapper" => "test2")
> ],
> "operation" => "add",
> "permissions" => [{
> "class-name" => "abc",
> "action" => undefined, <=== should be ""
> "target-name" => undefined <=== should be ""
> }]
> }
> {code}
> *Blank strings are interpreted as undefined value by CLI parser.*
> Problem is somewhere in *wildfly-core/cli*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2171?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2171 at 6/9/17 2:49 AM:
--------------------------------------------------------
The current impl of {{TransferQueueBundler}} calls {{take()}} on the main-queue, then {{drainTo()}}. This acquires the lock on the main-queue twice, which is bad as sender threads also acquire the same lock to add their messages to the main queue.
Since there is no blocking {{drainTo()}}, let's implement this in {{RingBuffer}} and use {{RingBuffer}} instead of {{ArrayBlockingQueue}} for the main-queue. Having the bundler thread lock the main-queue once instead of twice should result in less contention on the main-queue, and perhaps slightly better perf, and it would also simplify the code.
Perhaps the simplification is the more important aspect, as {{take()}} is only called when the inner loop calling {{drainTo()}} terminated, no more message were in the main-queue. This should not happen often when many message are sent.
was (Author: belaban):
The current impl of {{TransferQueueBundler}} calls {{take()}} on the main-queue, then {{drainTo()}}. This acquires the lock on the main-queue twice, which is bad as sender threads also acquire the same lock to add their messages to the main queue.
Since there is no blocking {{drainTo()}}, let's implement this in {{RingBuffer}} and use {{RingBuffer}} instead of {{ArrayBlockingQueue}} for the main-queue. Having the bundler thread lock the main-queue once instead of twice should result in less contention on the main-queue, and perhaps slightly better perf.
> New bundler with max_bundle_size for each destination
> -----------------------------------------------------
>
> Key: JGRP-2171
> URL: https://issues.jboss.org/browse/JGRP-2171
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.
> This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).
> The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.
> This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).
> We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.
> So 1 main queue and 1 queue for each destination.
> h4. Example:
> * {{num_flips}} is 2
> * A message for A is sent, added to the main queue and removed by the runner. It is queued in A's queue
> * Another message for A is sent. Also queued (A's queue: {{A A}})
> * A message to B is sent: A's {{num_flips}} is now 1. A's queue is {{A A}}, B's queue is {{B}}
> * Another message to A is sent. This resets A's {{num_flips}} to 2, B's {{num_flips}} is now 1
> * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
> * No more messages are received, so the batch to C is also sent
> The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).
> h4. Misc
> * Should the sending of batches be delegated to a thread pool?
> * Should the senders add their messages directly to the destination queues instead of the main queue? That would result in less contention on the main queue, but it would also require 1 thread per destination queue, which creates too many threads...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2171?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2171:
--------------------------------
The current impl of {{TransferQueueBundler}} calls {{take()}} on the main-queue, then {{drainTo()}}. This acquires the lock on the main-queue twice, which is bad as sender threads also acquire the same lock to add their messages to the main queue.
Since there is no blocking {{drainTo()}}, let's implement this in {{RingBuffer}} and use {{RingBuffer}} instead of {{ArrayBlockingQueue}} for the main-queue. Having the bundler thread lock the main-queue once instead of twice should result in less contention on the main-queue, and perhaps slightly better perf.
> New bundler with max_bundle_size for each destination
> -----------------------------------------------------
>
> Key: JGRP-2171
> URL: https://issues.jboss.org/browse/JGRP-2171
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.4
>
>
> The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent.
> This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway).
> The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent.
> This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s).
> We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination.
> So 1 main queue and 1 queue for each destination.
> h4. Example:
> * {{num_flips}} is 2
> * A message for A is sent, added to the main queue and removed by the runner. It is queued in A's queue
> * Another message for A is sent. Also queued (A's queue: {{A A}})
> * A message to B is sent: A's {{num_flips}} is now 1. A's queue is {{A A}}, B's queue is {{B}}
> * Another message to A is sent. This resets A's {{num_flips}} to 2, B's {{num_flips}} is now 1
> * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent
> * No more messages are received, so the batch to C is also sent
> The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination).
> h4. Misc
> * Should the sending of batches be delegated to a thread pool?
> * Should the senders add their messages directly to the destination queues instead of the main queue? That would result in less contention on the main queue, but it would also require 1 thread per destination queue, which creates too many threads...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8910) On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8910:
-----------------------------------------------
Durgesh Anaokar <danaokar(a)redhat.com> changed the Status of [bug 1459769|https://bugzilla.redhat.com/show_bug.cgi?id=1459769] from NEW to ASSIGNED
> On Windows, when running standalone/Domain with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8910
> URL: https://issues.jboss.org/browse/WFLY-8910
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 11.0.0.Alpha1
> Environment: Windows
> Reporter: Durgesh Anaokar
> Assignee: Durgesh Anaokar
> Priority: Minor
>
> On Windows 7, when running standalone.bat with the JAVA_HOME environment variable set (but pointing to an empty directory), JBoss EAP fails to start and does not give an error message.
> On line 177 of the standalone.bat, a check is made to see if the JAVA_HOME variable points to a valid directory. If it does, it assumes this directory contains bin\java. If bin\java does not exist, the server fails to start and does not give a reason why.
> expect to see an error message such as "%JAVA_HOME% path doesn't contain an executable at %JAVA_HOME%\bin\java"
> Add additional checks in the standalone.conf to verify that %JAVA_HOME%\bin\java exists and warn if it does not.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1237) Coverity, Resource leak in SecurityIdentity (Elytron)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1237?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1237:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Coverity, Resource leak in SecurityIdentity (Elytron)
> -----------------------------------------------------
>
> Key: ELY-1237
> URL: https://issues.jboss.org/browse/ELY-1237
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Critical
>
> Coverity found possible resource leak. On 2 places there is created ServerAuthenticationContext in SecurityIdentity but is not closed.
> {code}
> public SecurityIdentity createRunAsIdentity(Principal principal, boolean authorize) throws SecurityException {
> Assert.checkNotNullParam("principal", principal);
> // rewrite principal
> final SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(SET_RUN_AS_PERMISSION);
> }
> final ServerAuthenticationContext context = securityDomain.createNewAuthenticationContext(this, MechanismConfigurationSelector.constantSelector(MechanismConfiguration.EMPTY));
> try {
> if (! (context.importIdentity(this) && context.authorize(principal, authorize))) {
> throw log.runAsAuthorizationFailed(this.principal, principal, null);
> }
> } catch (RealmUnavailableException e) {
> throw log.runAsAuthorizationFailed(this.principal, context.getAuthenticationPrincipal(), e);
> }
> return context.getAuthorizedIdentity();
> }
> public SecurityIdentity createRunAsAnonymous(boolean authorize) throws SecurityException {
> final SecurityManager sm = System.getSecurityManager();
> if (sm != null) {
> sm.checkPermission(SET_RUN_AS_PERMISSION);
> }
> final ServerAuthenticationContext context = securityDomain.createNewAuthenticationContext(this, MechanismConfigurationSelector.constantSelector(MechanismConfiguration.EMPTY));
> if (! context.authorizeAnonymous(authorize)) {
> throw log.runAsAuthorizationFailed(principal, AnonymousPrincipal.getInstance(), null);
> }
> return context.getAuthorizedIdentity();
> }
> {code}
> In SecurityDomainTrustManager newly created ServerAuthenticationContext is closed in try-with-resource
> {code}
> try (final ServerAuthenticationContext authenticationContext = securityDomain.createNewAuthenticationContext(mechanismConfigurationSelector)) {
> {code}
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=22525...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-1237) Coverity, Resource leak in SecurityIdentity (Elytron)
by Martin Choma (JIRA)
Martin Choma created ELY-1237:
---------------------------------
Summary: Coverity, Resource leak in SecurityIdentity (Elytron)
Key: ELY-1237
URL: https://issues.jboss.org/browse/ELY-1237
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Critical
Coverity found possible resource leak. On 2 places there is created ServerAuthenticationContext in SecurityIdentity but is not closed.
{code}
public SecurityIdentity createRunAsIdentity(Principal principal, boolean authorize) throws SecurityException {
Assert.checkNotNullParam("principal", principal);
// rewrite principal
final SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(SET_RUN_AS_PERMISSION);
}
final ServerAuthenticationContext context = securityDomain.createNewAuthenticationContext(this, MechanismConfigurationSelector.constantSelector(MechanismConfiguration.EMPTY));
try {
if (! (context.importIdentity(this) && context.authorize(principal, authorize))) {
throw log.runAsAuthorizationFailed(this.principal, principal, null);
}
} catch (RealmUnavailableException e) {
throw log.runAsAuthorizationFailed(this.principal, context.getAuthenticationPrincipal(), e);
}
return context.getAuthorizedIdentity();
}
public SecurityIdentity createRunAsAnonymous(boolean authorize) throws SecurityException {
final SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(SET_RUN_AS_PERMISSION);
}
final ServerAuthenticationContext context = securityDomain.createNewAuthenticationContext(this, MechanismConfigurationSelector.constantSelector(MechanismConfiguration.EMPTY));
if (! context.authorizeAnonymous(authorize)) {
throw log.runAsAuthorizationFailed(principal, AnonymousPrincipal.getInstance(), null);
}
return context.getAuthorizedIdentity();
}
{code}
In SecurityDomainTrustManager newly created ServerAuthenticationContext is closed in try-with-resource
{code}
try (final ServerAuthenticationContext authenticationContext = securityDomain.createNewAuthenticationContext(mechanismConfigurationSelector)) {
{code}
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=22525...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month