[JBoss JIRA] (ISPN-4313) If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4313?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4313:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2575
> If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4313
> URL: https://issues.jboss.org/browse/ISPN-4313
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Security, Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Tristan Tarrant
> Priority: Critical
>
> Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
> <hotrod-connector socket-binding="hotrod" cache-container="security">
> ....
> <encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
> ....
> </hotrod>
> But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
> If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
> Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown in the server's logs:
> javax.net.ssl.SSLHandshakeException: null cert chain
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4313) If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4313?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4313:
-------------------------------------
Assignee: Tristan Tarrant (was: Dan Berindei)
> If Hotrod Server encryption's require-ssl-client-auth is set to true, <truststore .. /> existence must be checked
> -----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4313
> URL: https://issues.jboss.org/browse/ISPN-4313
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Security, Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Tristan Tarrant
> Priority: Critical
>
> Currently the Infinispan Server can be configured with SSL encryption such that it requires the client to authenticate itself to the server for the purposes of encryption. This can be done by setting the attribute require-ssl-client-auth="true" as shown below.
> <hotrod-connector socket-binding="hotrod" cache-container="security">
> ....
> <encryption security-realm="ApplicationRealm" require-ssl-client-auth="true"/>
> ....
> </hotrod>
> But when that attribute is set to "true" a check should be enforced to check the existence of the the <truststore .. /> element exists in secruity-realm's <authentication>.
> If the check on the configuration fails, the server should throw and error on bootup rather than fail when client connections start to come in.
> Currently when the require-ssl-client-auth="true" and there is no <truststore../> configured, client connections fail and the exception below is thrown in the server's logs:
> javax.net.ssl.SSLHandshakeException: null cert chain
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3877:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1096726|https://bugzilla.redhat.com/show_bug.cgi?id=1096726] from ON_QA to VERIFIED
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha4
>
> Attachments: PersistentQueue.java
>
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3894:
-----------------------------------------------
Alan Field <afield(a)redhat.com> changed the Status of [bug 1096727|https://bugzilla.redhat.com/show_bug.cgi?id=1096727] from ON_QA to VERIFIED
> SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
> ----------------------------------------------------------------------------------
>
> Key: ISPN-3894
> URL: https://issues.jboss.org/browse/ISPN-3894
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2
> Reporter: Rajesh Jangam
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha4
>
> Attachments: CoalesceEntries.java
>
>
> This issue is related to issue ISPN-3877.
> Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire.
> 1. Smaller entries expire and new bigger entries start getting added
> 2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries.
> 3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size.
> The optimization proposed is to:
> 1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries.
> 2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries:
> a. First part equal to the length being requested
> This is returned as a part of the allocation activity.
> b. Second part equal to the remainder of the space.
> This added back as a free entry to the freeList.
> Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent.
> This reduces file size of the store.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4319) ProtobufMatcherEvalContext should also fire missing properties
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-4319?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-4319:
--------------------------------
Description:
Not doing so leads to 'is null' predicates not being evaluated precisely because the property is null, which leads to an incorrect match result. This issue does not happen in the reflection based case.
Missing properties should be fired with their default value if they have one, otherwise with null, unless their type is not nullable in which case nothing needs to be done for them.
was:Not doing so leads to 'is null' not being evaluated.
> ProtobufMatcherEvalContext should also fire missing properties
> --------------------------------------------------------------
>
> Key: ISPN-4319
> URL: https://issues.jboss.org/browse/ISPN-4319
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 7.0.0.Alpha4
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Beta1
>
>
> Not doing so leads to 'is null' predicates not being evaluated precisely because the property is null, which leads to an incorrect match result. This issue does not happen in the reflection based case.
> Missing properties should be fired with their default value if they have one, otherwise with null, unless their type is not nullable in which case nothing needs to be done for them.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (ISPN-4298) HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4298?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4298:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1099054|https://bugzilla.redhat.com/show_bug.cgi?id=1099054] from ON_QA to VERIFIED
> HotRod kerberos auth doesn't see the ticket when creating RemoteCachManager
> ---------------------------------------------------------------------------
>
> Key: ISPN-4298
> URL: https://issues.jboss.org/browse/ISPN-4298
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Beta1
>
>
> When HR client obtains initial GSSAPI challenge (usually when creating {{RemoteCachManager}}), it fails with
> {noformat}
> Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
> at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:67)
> at org.infinispan.client.hotrod.impl.transport.tcp.SaslTransportObjectFactory.makeObject(SaslTransportObjectFactory.java:25)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:306)
> ... 109 more
> Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
> at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:147)
> at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:121)
> at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
> at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:223)
> at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
> at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
> ... 113 more
> {noformat}
> When the code is wrapped by {{PrivilegedExceptionAction}}, e.g.
> {code}
> final Configuration config = getRemoteCacheManagerConfig(subj);
> Subject.doAs(subj, new PrivilegedExceptionAction<Void>() {
> public Void run() throws Exception {
> remoteCacheManager = new RemoteCacheManager(config, true);
> return null;
> }
> });
> {code}
> everything works fine
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months