[jira] [Commented] (IGNITE-14070) Protecting a snapshot from unauthorized changes
[ https://issues.apache.org/jira/browse/IGNITE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17358431#comment-17358431 ] Denis Garus commented on IGNITE-14070: -- Hi, [~xtern]! Ok > Protecting a snapshot from unauthorized changes > --- > > Key: IGNITE-14070 > URL: https://issues.apache.org/jira/browse/IGNITE-14070 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Garus >Priority: Major > Labels: iep-43 > Time Spent: 10m > Remaining Estimate: 0h > > We have to allow Ignite users to check the integrity of snapshot files before > restoring them. > This opportunity can be done through the Ignite plugin mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14070) Protecting a snapshot from unauthorized changes
[ https://issues.apache.org/jira/browse/IGNITE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-14070: Assignee: (was: Denis Garus) > Protecting a snapshot from unauthorized changes > --- > > Key: IGNITE-14070 > URL: https://issues.apache.org/jira/browse/IGNITE-14070 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Garus >Priority: Major > Labels: iep-43 > Time Spent: 10m > Remaining Estimate: 0h > > We have to allow Ignite users to check the integrity of snapshot files before > restoring them. > This opportunity can be done through the Ignite plugin mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311298#comment-17311298
]
Denis Garus edited comment on IGNITE-14335 at 3/30/21, 9:05 AM:
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
was (Author: garus.d.g):
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
>
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311298#comment-17311298
]
Denis Garus commented on IGNITE-14335:
--
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
apply a security policy, so authorization does not make sense
authenticate clients, except SQL clients
get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311298#comment-17311298
]
Denis Garus edited comment on IGNITE-14335 at 3/30/21, 9:05 AM:
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
* apply a security policy, so authorization does not make sense
* authenticate clients, except SQL clients
* get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
was (Author: garus.d.g):
[~PetrovMikhail]
Suggested realization provides a security plugin when
{{isAuthenticationEnabled}} is {{true}} and, in this way, makes
{{IgniteSecurity}} enabled. But current implementation of
{{IgniteAuthenticationProcessor}} (security plugin) does not allow:
apply a security policy, so authorization does not make sense
authenticate clients, except SQL clients
get the actual security context by a security subject id.
Another hand, security-enabled mode adds to every communication message a
security subject id, makes a security context switch, authorizes an operation,
and so on that is a waste of resources.
Thus, let's implement a worthy default security plugin or choose another way to
realize this task.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
>
[jira] [Commented] (IGNITE-14414) Cluster initialization flow
[ https://issues.apache.org/jira/browse/IGNITE-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308705#comment-17308705 ] Denis Garus commented on IGNITE-14414: -- Is this issue really a bug? > Cluster initialization flow > --- > > Key: IGNITE-14414 > URL: https://issues.apache.org/jira/browse/IGNITE-14414 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > For a cluster to become operational, the metastorage instance must be > initialized first. The initialization command chooses a set of nodes > (normally, 3 - 5 nodes) to host the distributed metastorage Raft group. When > a node receives the initialization command, it either creates a bootstrapped > Raft instance with the given members (if this is a metastorage group node), > or writes the metastorage group member IDs to the vault as a private > system-level property. > After the metastorage is initialized, components start to receive and process > watch events, updating the local state according to the changes received from > the watch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) The current security context should be obtained using the IgniteSecurity interface only.
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Description: For getting the current security context, we have to use the IgniteSecurity interface only. We need to get rid of all other ways to transfer a security subject id. h4. Suggested implementation If Ignite Security (IS) is enabled, then executors, accessed through the PoolProcessor, are wrapped to a security-aware implementation. Security-aware implementation sets proper security context for tasks that the executor performs. The field subject id was deleted from communication requests for cache and compute operations; a remote node gets the subject id that initiates the ignite operation from GridIoSecurityAwareMessage. IgniteSecurity uses this id to set a proper security context during the execution of the request. Remove GridTaskThreadContextKey#TC_SUBJ_ID, GridCacheContext#subjectIdPerCall; a consumer has to obtain a current security subject id through IgniteSecurity or the set of SecurityUtils methods. For all events that include the subject id field, are set the following rule. If IS is enabled, this field must contain a subject id that initiates an ignite operation, otherwise null. Implement SecurityAwareCustomMessageWrapper for discovery requests that act as GridIoSecurityAwareMessage for communication requests. It allows setting proper context during the discovery message execution. Implement SecurityAwareGridRestCommandHandler to allow GridRestProcessor to execute all client requests with the proper security context. was: For getting the current security context, we have to use the IgniteSecurity interface only. We need to get rid of all other ways to transfer a security subject id. > The current security context should be obtained using the IgniteSecurity > interface only. > > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Time Spent: 4h 50m > Remaining Estimate: 0h > > For getting the current security context, we have to use the IgniteSecurity > interface only. > We need to get rid of all other ways to transfer a security subject id. > h4. Suggested implementation > If Ignite Security (IS) is enabled, then executors, accessed through the > PoolProcessor, are wrapped to a security-aware implementation. Security-aware > implementation sets proper security context for tasks that the executor > performs. > The field subject id was deleted from communication requests for cache and > compute operations; a remote node gets the subject id that initiates the > ignite operation from GridIoSecurityAwareMessage. IgniteSecurity uses this id > to set a proper security context during the execution of the request. > Remove GridTaskThreadContextKey#TC_SUBJ_ID, > GridCacheContext#subjectIdPerCall; a consumer has to obtain a current > security subject id through IgniteSecurity or the set of SecurityUtils > methods. > For all events that include the subject id field, are set the following rule. > If IS is enabled, this field must contain a subject id that initiates an > ignite operation, otherwise null. > Implement SecurityAwareCustomMessageWrapper for discovery requests that act > as GridIoSecurityAwareMessage for communication requests. It allows setting > proper context during the discovery message execution. > Implement SecurityAwareGridRestCommandHandler to allow GridRestProcessor to > execute all client requests with the proper security context. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
[ https://issues.apache.org/jira/browse/IGNITE-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305385#comment-17305385 ] Denis Garus commented on IGNITE-14179: -- [~renni] LGTM > The GridDhtTxFinishFuture has the redundant interface declaration > 'GridCacheFuture' > -- > > Key: IGNITE-14179 > URL: https://issues.apache.org/jira/browse/IGNITE-14179 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Priority: Minor > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
[ https://issues.apache.org/jira/browse/IGNITE-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303863#comment-17303863 ] Denis Garus commented on IGNITE-14179: -- [~renni] Hi, sure. > The GridDhtTxFinishFuture has the redundant interface declaration > 'GridCacheFuture' > -- > > Key: IGNITE-14179 > URL: https://issues.apache.org/jira/browse/IGNITE-14179 > Project: Ignite > Issue Type: Bug >Reporter: Denis Garus >Priority: Minor > Labels: newbie > > Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14317) IgniteCache.removeAsync(key,val) fails inside an optimistic transaction
Denis Garus created IGNITE-14317:
Summary: IgniteCache.removeAsync(key,val) fails inside an
optimistic transaction
Key: IGNITE-14317
URL: https://issues.apache.org/jira/browse/IGNITE-14317
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Denis Garus
[reproducer|https://github.com/apache/ignite/pull/8841/files]
IgniteCache.removeAsync(key,val) fails inside an optimistic tx with the
exception:
{code:java}
[17:39:28] (err) Failed to notify listener:
o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError[17:39:28]
(err) Failed to notify listener:
o.a.i.i.processors.cache.distributed.near.GridNearTxLocal$6...@19c520dbjava.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2955)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$17.apply(GridNearTxLocal.java:2937)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.processLoaded(GridNearTxLocal.java:3475)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3217)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$21.apply(GridNearTxLocal.java:3212)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
at
org.apache.ignite.internal.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
at
org.apache.ignite.internal.processors.cache.GridCacheFutureAdapter.onDone(GridCacheFutureAdapter.java:55)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onDone(GridPartitionedSingleGetFuture.java:935)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:467)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setSkipValueResult(GridPartitionedSingleGetFuture.java:759)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:636)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:88)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:133)
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:131)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1143)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1908)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1529)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1422)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14179) The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture'
Denis Garus created IGNITE-14179: Summary: The GridDhtTxFinishFuture has the redundant interface declaration 'GridCacheFuture' Key: IGNITE-14179 URL: https://issues.apache.org/jira/browse/IGNITE-14179 Project: Ignite Issue Type: Bug Reporter: Denis Garus Remove redundant interface declaration 'GridCacheFuture' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13472) JDBC bulkload operations are processed with wrong security context
[
https://issues.apache.org/jira/browse/IGNITE-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17272889#comment-17272889
]
Denis Garus commented on IGNITE-13472:
--
[~SomeFire] LGTM
> JDBC bulkload operations are processed with wrong security context
> --
>
> Key: IGNITE-13472
> URL: https://issues.apache.org/jira/browse/IGNITE-13472
> Project: Ignite
> Issue Type: Bug
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JdbcAuthorizationTest.testCopyFrom()}} have many exceptions like
> {code:java}
> [12:02:56] (err) Failed to execute compound future reducer:
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false,
> cancelled=false, err=null, futs=TransformCollectionView [true]]class
> org.apache.ignite.IgniteCheckedException: Authorization failed
> [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7589)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:979)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.plugin.security.SecurityException:
> Authorization failed [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.processors.security.impl.TestSecurityProcessor.authorize(TestSecurityProcessor.java:153)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:207)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.checkSecurityPermission(DataStreamerUpdateJob.java:170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:123)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7087)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:971)
> ... 4 more
> {code}
> This exception means the put operation is processed with node context instead
> of user. Also, operation doesn't finish successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14070) Protecting a snapshot from unauthorized changes
[ https://issues.apache.org/jira/browse/IGNITE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-14070: - Summary: Protecting a snapshot from unauthorized changes (was: Protecting a snapshot from from unauthorized changes) > Protecting a snapshot from unauthorized changes > --- > > Key: IGNITE-14070 > URL: https://issues.apache.org/jira/browse/IGNITE-14070 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-43 > > We have to allow Ignite users to check the integrity of snapshot files before > restoring them. > This opportunity can be done through the Ignite plugin mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14070) Protecting a snapshot from from unauthorized changes
Denis Garus created IGNITE-14070: Summary: Protecting a snapshot from from unauthorized changes Key: IGNITE-14070 URL: https://issues.apache.org/jira/browse/IGNITE-14070 Project: Ignite Issue Type: New Feature Reporter: Denis Garus Assignee: Denis Garus We have to allow Ignite users to check the integrity of snapshot files before restoring them. This opportunity can be done through the Ignite plugin mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
[ https://issues.apache.org/jira/browse/IGNITE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225278#comment-17225278 ] Denis Garus commented on IGNITE-13652: -- [~dmagda] Hello Denis! Sorry, the long commits history is my fault, fixed. > Wrong GitHub link for Apache Ignite With Spring Data/Example > > > Key: IGNITE-13652 > URL: https://issues.apache.org/jira/browse/IGNITE-13652 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.9 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: docuentation > > Wrong GihHub link in > https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
[ https://issues.apache.org/jira/browse/IGNITE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224627#comment-17224627 ] Denis Garus commented on IGNITE-13652: -- [~dmagda] Denis hello! Could you please pay attention to this simple issue? > Wrong GitHub link for Apache Ignite With Spring Data/Example > > > Key: IGNITE-13652 > URL: https://issues.apache.org/jira/browse/IGNITE-13652 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.9 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: docuentation > > Wrong GihHub link in > https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
[ https://issues.apache.org/jira/browse/IGNITE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-13652: Assignee: Denis Garus > Wrong GitHub link for Apache Ignite With Spring Data/Example > > > Key: IGNITE-13652 > URL: https://issues.apache.org/jira/browse/IGNITE-13652 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.9 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: docuentation > > Wrong GihHub link in > https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13652) Wrong GitHub link for Apache Ignite With Spring Data/Example
Denis Garus created IGNITE-13652: Summary: Wrong GitHub link for Apache Ignite With Spring Data/Example Key: IGNITE-13652 URL: https://issues.apache.org/jira/browse/IGNITE-13652 Project: Ignite Issue Type: Bug Components: documentation Affects Versions: 2.9 Reporter: Denis Garus Wrong GihHub link in https://ignite.apache.org/docs/latest/extensions-and-integrations/spring/spring-data#example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Description: For getting the current security context, we have to use the IgniteSecurity interface only. We need to get rid of all other ways to transfer a security subject id. was: CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have fieldCacheEvent#subjectId always null. CacheEvent#subjectId should be subject id associated with SecuritySubject that trigged the cache event. > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Time Spent: 4h 40m > Remaining Estimate: 0h > > For getting the current security context, we have to use the IgniteSecurity > interface only. > We need to get rid of all other ways to transfer a security subject id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) The current security context should be obtained using the IgniteSecurity interface only.
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Summary: The current security context should be obtained using the IgniteSecurity interface only. (was: CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED) > The current security context should be obtained using the IgniteSecurity > interface only. > > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Time Spent: 4h 40m > Remaining Estimate: 0h > > For getting the current security context, we have to use the IgniteSecurity > interface only. > We need to get rid of all other ways to transfer a security subject id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13535) Support cluster snapshot security permissions
[ https://issues.apache.org/jira/browse/IGNITE-13535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213017#comment-17213017 ] Denis Garus commented on IGNITE-13535: -- [~mmuzaf] Hello! LGTM > Support cluster snapshot security permissions > - > > Key: IGNITE-13535 > URL: https://issues.apache.org/jira/browse/IGNITE-13535 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to add a capability to specify permissions to allow/disallow executions > of cluster snapshot operation. > The following permissions should be added to the SecurityPermission enum: > - ADMIN_SNAPSHOT_OPS - for creating/cancelling snapshot opreation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache's operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Summary: Cache's operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. (was: Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.) > Cache's operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > - > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains: > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains: * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains_:_ * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains: > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndXXX_ operation is executed. A transaction cache works fine. _getAndXXX_ contains_:_ * _getAndPut_ * _getAndPutAsync_ * _getAndPutIfAbsent_ * _getAndPutIfAbsentAsync_ * _getAndRemove_ * _getAndRemoveAsync_ * _getAndReplace_ * _getAndReplaceAsync_ The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operations are executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndXXX_ operation is executed. > A transaction cache works fine. > _getAndXXX_ contains_:_ > * _getAndPut_ > * _getAndPutAsync_ > * _getAndPutIfAbsent_ > * _getAndPutIfAbsentAsync_ > * _getAndRemove_ > * _getAndRemoveAsync_ > * _getAndReplace_ > * _getAndReplaceAsync_ > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Summary: Cache operation getAndXXX doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. (was: Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.) > Cache operation getAndXXX doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operations are executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operations are executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operations are executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, getAndPutIfAbsentAsync_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut, getAndPutAsync, getAndPutIfAbsent, > getAndPutIfAbsentAsync_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut (getAndPutAsync)_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
[ https://issues.apache.org/jira/browse/IGNITE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13490: - Description: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer is in the attachment. was: An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer in the attachment. > Cache operation getAndPut doesn't trigger a CacheEvent with type > EVT_CACHE_OBJECT_READ. > --- > > Key: IGNITE-13490 > URL: https://issues.apache.org/jira/browse/IGNITE-13490 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Denis Garus >Priority: Major > Attachments: GetAndPutCacheEventsTest.java > > > An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ > for a remote filter when _getAndPut_ operation is executed. > A transaction cache works fine. > The reproducer is in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13490) Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ.
Denis Garus created IGNITE-13490: Summary: Cache operation getAndPut doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ. Key: IGNITE-13490 URL: https://issues.apache.org/jira/browse/IGNITE-13490 Project: Ignite Issue Type: Bug Components: cache Reporter: Denis Garus Attachments: GetAndPutCacheEventsTest.java An atomic cache doesn't trigger a CacheEvent with type EVT_CACHE_OBJECT_READ for a remote filter when _getAndPut_ operation is executed. A transaction cache works fine. The reproducer in the attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201949#comment-17201949 ] Denis Garus commented on IGNITE-12443: -- [~dmagda] Great! Thank you very much! > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38, important > Fix For: 2.9 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201311#comment-17201311 ] Denis Garus commented on IGNITE-12443: -- [~dmagda] Hello, Denis! Thank you very much for your suggestions! I fixed the PR, but I don't have write access to merge it. > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38, important > Fix For: 2.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198202#comment-17198202 ] Denis Garus commented on IGNITE-12443: -- [~dmagda] Hello, Denis! Thank you for your feedback! I tried to solve your comments. Could you please have a look? > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38, important > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13401) Unsupported protocol version exception when getting cache configuration from Java thin client
[
https://issues.apache.org/jira/browse/IGNITE-13401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17194098#comment-17194098
]
Denis Garus commented on IGNITE-13401:
--
[~alex_pl], hello!
Your PR looks good for me.
> Unsupported protocol version exception when getting cache configuration from
> Java thin client
> -
>
> Key: IGNITE-13401
> URL: https://issues.apache.org/jira/browse/IGNITE-13401
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Marcus Lo
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We encounter BinaryObjectException: Unsupported protocol version: 8 in one of
> our tables in Ignite when querying cache configuration via Java thin client.
> To reproduce:
> # Setup Ignite with persistence disabled (single node)
> # Create the follow table:
> {code:java}
> CREATE TABLE IF NOT EXISTS LEOD_CONTEXT_STATUS
> (
> flashNode VARCHAR NOT NULL,
> legalEntity VARCHAR NOT NULL,
> account VARCHAR NOT NULL,
> userIdVARCHAR NOT NULL,
> eqtgContext VARCHAR NOT NULL,
> submissionDateINT NOT NULL,
> actionVARCHAR NOT NULL,
> actionTimeTIME NOT NULL,
> runNumber INT NOT NULL,
> segment VARCHAR NOT NULL,
> geography VARCHAR NOT NULL,
> priceVersion VARCHAR NOT NULL,
> statusVARCHAR NOT NULL,
> errorCountINT NOT NULL,
> comments VARCHAR,
> equityDeltaLowerBound DOUBLE,
> equityDeltaUpperBound DOUBLE,
> equityDeltaUtil DOUBLE,
> equityVegaLowerBound DOUBLE,
> equityVegaUpperBound DOUBLE,
> equityVegaUtilDOUBLE,
> lastUpdateTimeTIMESTAMP NOT NULL,
> PRIMARY KEY (flashNode, legalEntity, account, submissionDate)
> )
> WITH "template=REPLICATED, cache_name=LeodContextStatusCache";{code}
> # Run the following test (in Kotlin):
> {code:java}
> @Test
> fun `moo`() {
> val config = ClientConfiguration()
> .setAddresses("localhost:10800")
> val ignite = Ignition.startClient(config)
> ignite.cache("LeodContextStatusCache")
> .configuration
> }
> {code}
> # It fails in the following exception:
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 8
> at
> org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:796)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:221)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:165)
> at
> org.apache.ignite.internal.client.thin.ClientUtils.cacheConfiguration(ClientUtils.java:381)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.lambda$getConfiguration$2(TcpClientCache.java:160)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.receive(TcpClientChannel.java:247)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:171)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:180)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.getConfiguration(TcpClientCache.java:155)
> {code}
> I notice that if any one of the columns is removed, the issue disappears.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12443: - Ignite Flags: (was: Docs Required,Release Notes Required) > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38, important > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193559#comment-17193559 ] Denis Garus commented on IGNITE-12443: -- [~Artem Budnikov], can you please have a look? > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38, important > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13301) IgniteScheduler has to run inside the Ignite Sandbox with appropriate security context.
[
https://issues.apache.org/jira/browse/IGNITE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168455#comment-17168455
]
Denis Garus commented on IGNITE-13301:
--
[~alex_pl] thank you!
> IgniteScheduler has to run inside the Ignite Sandbox with appropriate
> security context.
> ---
>
> Key: IGNITE-13301
> URL: https://issues.apache.org/jira/browse/IGNITE-13301
> Project: Ignite
> Issue Type: Task
> Components: security
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
> Labels: iep-38
> Fix For: 2.10
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> IgniteScheduler has to run inside the Ignite Sandbox on a remote node.
> For example:
> {code:java}
> Ignition.localIgnite().compute().run(() -> {
> IgniteScheduler scheduler = Ignition.localIgnite().scheduler();
> scheduler.runLocal(AbstractSandboxTest::controlAction).get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13312) Methods of interface Binarylizable should not get access to host resources.
[ https://issues.apache.org/jira/browse/IGNITE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17168432#comment-17168432 ] Denis Garus commented on IGNITE-13312: -- [~daradurvs] Hello! Could you please review the PR? > Methods of interface Binarylizable should not get access to host resources. > --- > > Key: IGNITE-13312 > URL: https://issues.apache.org/jira/browse/IGNITE-13312 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 0.5h > Remaining Estimate: 0h > > Methods of interface Binarylizable should not get access to host resources on > remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13312) Methods of interface Binarylizable should not get access to host resources.
[ https://issues.apache.org/jira/browse/IGNITE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13312: - Description: Methods of interface Binarylizable should not get access to host resources on remote nodes. (was: Methods of interface Binarylizable should not get accessing to host resources on a remote nodes.) > Methods of interface Binarylizable should not get access to host resources. > --- > > Key: IGNITE-13312 > URL: https://issues.apache.org/jira/browse/IGNITE-13312 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 20m > Remaining Estimate: 0h > > Methods of interface Binarylizable should not get access to host resources on > remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13312) Methods of interface Binarylizable should not get access to host resources.
[ https://issues.apache.org/jira/browse/IGNITE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13312: - Summary: Methods of interface Binarylizable should not get access to host resources. (was: Methods of interface Binarylizable should not get accessing to host resources.) > Methods of interface Binarylizable should not get access to host resources. > --- > > Key: IGNITE-13312 > URL: https://issues.apache.org/jira/browse/IGNITE-13312 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 20m > Remaining Estimate: 0h > > Methods of interface Binarylizable should not get accessing to host resources > on a remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13312) Methods of interface Binarylizable should not get accessing to host resources.
[ https://issues.apache.org/jira/browse/IGNITE-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-13312: Assignee: Denis Garus > Methods of interface Binarylizable should not get accessing to host resources. > -- > > Key: IGNITE-13312 > URL: https://issues.apache.org/jira/browse/IGNITE-13312 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Methods of interface Binarylizable should not get accessing to host resources > on a remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13312) Methods of interface Binarylizable should not get accessing to host resources.
Denis Garus created IGNITE-13312: Summary: Methods of interface Binarylizable should not get accessing to host resources. Key: IGNITE-13312 URL: https://issues.apache.org/jira/browse/IGNITE-13312 Project: Ignite Issue Type: Task Components: security Reporter: Denis Garus Methods of interface Binarylizable should not get accessing to host resources on a remote nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13301) IgniteScheduler has to run inside the Ignite Sandbox with appropriate security context.
[
https://issues.apache.org/jira/browse/IGNITE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus updated IGNITE-13301:
-
Summary: IgniteScheduler has to run inside the Ignite Sandbox with
appropriate security context. (was: IgniteScheduler has to run inside the
Ignite Sandbox.)
> IgniteScheduler has to run inside the Ignite Sandbox with appropriate
> security context.
> ---
>
> Key: IGNITE-13301
> URL: https://issues.apache.org/jira/browse/IGNITE-13301
> Project: Ignite
> Issue Type: Task
> Components: security
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
> Labels: iep-38
>
> IgniteScheduler has to run inside the Ignite Sandbox on a remote node.
> For example:
> {code:java}
> Ignition.localIgnite().compute().run(() -> {
> IgniteScheduler scheduler = Ignition.localIgnite().scheduler();
> scheduler.runLocal(AbstractSandboxTest::controlAction).get();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13300) Ignite sandbox vulnerability allows to execute user code in privileged proxy
[
https://issues.apache.org/jira/browse/IGNITE-13300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17165697#comment-17165697
]
Denis Garus commented on IGNITE-13300:
--
[~alex_pl] LGTM
> Ignite sandbox vulnerability allows to execute user code in privileged proxy
>
>
> Key: IGNITE-13300
> URL: https://issues.apache.org/jira/browse/IGNITE-13300
> Project: Ignite
> Issue Type: Bug
> Components: security
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Critical
> Labels: iep-38, sandbox
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite sandbox returns a privileged proxy for Ignite and some other system
> interfaces. If the user implements one of these interfaces and gets via
> privileged proxy an instance of implemented class, privileged proxy for user
> class will be returned.
> Reproducer:
> {code:java}
> public class PrivilegedProxyTest extends AbstractSandboxTest {
> public void testPrivelegedUserObject() throws Exception {
>
> grid(CLNT_FORBIDDEN_WRITE_PROP).getOrCreateCache(DEFAULT_CACHE_NAME).put(0,
> new TestIterator<>());
> runForbiddenOperation(() ->
> grid(CLNT_FORBIDDEN_WRITE_PROP).compute().run(() -> {
> GridIterator it =
> (GridIterator)Ignition.localIgnite().cache(DEFAULT_CACHE_NAME).get(0);
> it.iterator();
> }), AccessControlException.class);
> }
> public static class TestIterator extends GridIterableAdapter {
> public TestIterator() {
> super(Collections.emptyIterator());
> }
> @Override public GridIterator iterator() {
> controlAction();
> return super.iterator();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13301) IgniteScheduler has to run inside the Ignite Sandbox.
Denis Garus created IGNITE-13301:
Summary: IgniteScheduler has to run inside the Ignite Sandbox.
Key: IGNITE-13301
URL: https://issues.apache.org/jira/browse/IGNITE-13301
Project: Ignite
Issue Type: Task
Components: security
Reporter: Denis Garus
Assignee: Denis Garus
IgniteScheduler has to run inside the Ignite Sandbox on a remote node.
For example:
{code:java}
Ignition.localIgnite().compute().run(() -> {
IgniteScheduler scheduler = Ignition.localIgnite().scheduler();
scheduler.runLocal(AbstractSandboxTest::controlAction).get();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13300) Ignite sandbox vulnerability allows to execute user code in privileged proxy
[
https://issues.apache.org/jira/browse/IGNITE-13300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus updated IGNITE-13300:
-
Labels: iep-38 sandbox (was: sandbox)
> Ignite sandbox vulnerability allows to execute user code in privileged proxy
>
>
> Key: IGNITE-13300
> URL: https://issues.apache.org/jira/browse/IGNITE-13300
> Project: Ignite
> Issue Type: Bug
> Components: security
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Critical
> Labels: iep-38, sandbox
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite sandbox returns a privileged proxy for Ignite and some other system
> interfaces. If the user implements one of these interfaces and gets via
> privileged proxy an instance of implemented class, privileged proxy for user
> class will be returned.
> Reproducer:
> {code:java}
> public class PrivilegedProxyTest extends AbstractSandboxTest {
> public void testPrivelegedUserObject() throws Exception {
>
> grid(CLNT_FORBIDDEN_WRITE_PROP).getOrCreateCache(DEFAULT_CACHE_NAME).put(0,
> new TestIterator<>());
> runForbiddenOperation(() ->
> grid(CLNT_FORBIDDEN_WRITE_PROP).compute().run(() -> {
> GridIterator it =
> (GridIterator)Ignition.localIgnite().cache(DEFAULT_CACHE_NAME).get(0);
> it.iterator();
> }), AccessControlException.class);
> }
> public static class TestIterator extends GridIterableAdapter {
> public TestIterator() {
> super(Collections.emptyIterator());
> }
> @Override public GridIterator iterator() {
> controlAction();
> return super.iterator();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12996: - Release Note: A remote filter of IgniteEvents will run on a remote node inside the Ignite Sandbox if it is turned on. > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13261) Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException
[ https://issues.apache.org/jira/browse/IGNITE-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162098#comment-17162098 ] Denis Garus commented on IGNITE-13261: -- [~alex_pl] thank you! > Using transactions or scan queries inside the ignite sandbox can throw an > AccessControlException > > > Key: IGNITE-13261 > URL: https://issues.apache.org/jira/browse/IGNITE-13261 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Any subject should be able to use transactions or scan queries inside the > ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162099#comment-17162099 ] Denis Garus commented on IGNITE-12996: -- [~alex_pl] thank you! > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17161928#comment-17161928 ] Denis Garus commented on IGNITE-12996: -- [~alex_pl], could you please review the changes. There is one blocker in TC visa that also present on the master branch. Unfortunately, it blocks getting a green visa. > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 10m > Remaining Estimate: 0h > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12443) Document the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12443: Assignee: Denis Garus > Document the Ignite Sandbox > --- > > Key: IGNITE-12443 > URL: https://issues.apache.org/jira/browse/IGNITE-12443 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Document how to configure and use the Ignite Sandbox. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12996: - Description: Remote filter of IgniteEvents has to run on a remote node inside the Ignite Sandbox if it is turned on. (was: Remote listener of IgniteEvents has to run on a remote node inside the Ignite Sandbox if it is turned on.) > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote filter of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12996) Remote filter of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12996: - Summary: Remote filter of IgniteEvents has to run inside the Ignite Sandbox. (was: Remote listener of IgniteEvents has to run inside the Ignite Sandbox.) > Remote filter of IgniteEvents has to run inside the Ignite Sandbox. > --- > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote listener of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13228) Remote filter of IgniteEvents has to run with appropriate SecurityContext.
[ https://issues.apache.org/jira/browse/IGNITE-13228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13228: - Release Note: The remote filter of IgniteEvents runs on a remote node with the SecurityContext of the initiator node if security is on. > Remote filter of IgniteEvents has to run with appropriate SecurityContext. > -- > > Key: IGNITE-13228 > URL: https://issues.apache.org/jira/browse/IGNITE-13228 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 1h > Remaining Estimate: 0h > > The remote filter of IgniteEvents has to run on a remote node with the > SecurityContext of the initiator node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13228) Remote filter of IgniteEvents has to run with appropriate SecurityContext.
[ https://issues.apache.org/jira/browse/IGNITE-13228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159936#comment-17159936 ] Denis Garus commented on IGNITE-13228: -- [~alex_pl] thank you! > Remote filter of IgniteEvents has to run with appropriate SecurityContext. > -- > > Key: IGNITE-13228 > URL: https://issues.apache.org/jira/browse/IGNITE-13228 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 1h > Remaining Estimate: 0h > > The remote filter of IgniteEvents has to run on a remote node with the > SecurityContext of the initiator node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13261) Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException
[ https://issues.apache.org/jira/browse/IGNITE-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13261: - Description: Any subject should be able to use transactions or scan queries inside the ignite sandbox without additional permissions. (was: Any subject should be able to use transactions or continuous queries inside the ignite sandbox without additional permissions.) > Using transactions or scan queries inside the ignite sandbox can throw an > AccessControlException > > > Key: IGNITE-13261 > URL: https://issues.apache.org/jira/browse/IGNITE-13261 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Any subject should be able to use transactions or scan queries inside the > ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13261) Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException
[ https://issues.apache.org/jira/browse/IGNITE-13261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13261: - Summary: Using transactions or scan queries inside the ignite sandbox can throw an AccessControlException (was: Using transactions or continuous queries inside the ignite sandbox can throw an AccessControlException) > Using transactions or scan queries inside the ignite sandbox can throw an > AccessControlException > > > Key: IGNITE-13261 > URL: https://issues.apache.org/jira/browse/IGNITE-13261 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Any subject should be able to use transactions or continuous queries inside > the ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13261) Using transactions or continuous queries inside the ignite sandbox can throw an AccessControlException
Denis Garus created IGNITE-13261: Summary: Using transactions or continuous queries inside the ignite sandbox can throw an AccessControlException Key: IGNITE-13261 URL: https://issues.apache.org/jira/browse/IGNITE-13261 Project: Ignite Issue Type: Bug Components: security Reporter: Denis Garus Assignee: Denis Garus Any subject should be able to use transactions or continuous queries inside the ignite sandbox without additional permissions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13228) Remote filter of IgniteEvents has to run with appropriate SecurityContext.
Denis Garus created IGNITE-13228: Summary: Remote filter of IgniteEvents has to run with appropriate SecurityContext. Key: IGNITE-13228 URL: https://issues.apache.org/jira/browse/IGNITE-13228 Project: Ignite Issue Type: Improvement Components: security Affects Versions: 2.8.1 Reporter: Denis Garus Assignee: Denis Garus Fix For: 2.9 The remote filter of IgniteEvents has to run on a remote node with the SecurityContext of the initiator node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13010) A local listener for cache events with type EVT_CACHE_STOPPED does not get a cache event from a remote node.
[
https://issues.apache.org/jira/browse/IGNITE-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144909#comment-17144909
]
Denis Garus commented on IGNITE-13010:
--
[~nizhikov] Thanks for the review.
> A local listener for cache events with type EVT_CACHE_STOPPED does not get a
> cache event from a remote node.
>
>
> Key: IGNITE-13010
> URL: https://issues.apache.org/jira/browse/IGNITE-13010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A local listener for cache events with type EVT_CACHE_STOPPED does not get a
> cache event from a remote node.
> That occurs due to NPE on a remote node:
> {code:java}
> [2020-05-14
> 12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
> Failed to send event notification to node:
> 55671ec1-dad9-452b-8ab2-4b7916c0[2020-05-14
> 12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
> Failed to send event notification to node:
> 55671ec1-dad9-452b-8ab2-4b7916c0java.lang.NullPointerException at
> org.apache.ignite.internal.GridEventConsumeHandler$2$1.run(GridEventConsumeHandler.java:238)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The reproducer:
> {code:java}
> public class NpeGridEventConsumeHandlerReproducer extends
> GridCommonAbstractTest {
> private static AtomicInteger rmtCounter = new AtomicInteger();
> private static AtomicInteger locCounter = new AtomicInteger();
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return
> super.getConfiguration(igniteInstanceName).setIncludeEventTypes(EVT_CACHE_STOPPED);
> }
> @Test
> public void test() throws Exception {
> startGrids(3);
>
> grid(1).createCache(new CacheConfiguration<>("test_cache"));
> grid(0).events().remoteListen((uuid, evt) ->{
> locCounter.incrementAndGet();
> return true;
> }, evt->{
> rmtCounter.incrementAndGet();
> return true;
> }, EVT_CACHE_STOPPED);
> grid(1).destroyCache("test_cache");
> TimeUnit.SECONDS.sleep(10);
> assertEquals(rmtCounter.get(), locCounter.get());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13010) A local listener for cache events with type EVT_CACHE_STOPPED does not get a cache event from a remote node.
[
https://issues.apache.org/jira/browse/IGNITE-13010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Garus reassigned IGNITE-13010:
Assignee: Denis Garus
> A local listener for cache events with type EVT_CACHE_STOPPED does not get a
> cache event from a remote node.
>
>
> Key: IGNITE-13010
> URL: https://issues.apache.org/jira/browse/IGNITE-13010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
>
> A local listener for cache events with type EVT_CACHE_STOPPED does not get a
> cache event from a remote node.
> That occurs due to NPE on a remote node:
> {code:java}
> [2020-05-14
> 12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
> Failed to send event notification to node:
> 55671ec1-dad9-452b-8ab2-4b7916c0[2020-05-14
> 12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
> Failed to send event notification to node:
> 55671ec1-dad9-452b-8ab2-4b7916c0java.lang.NullPointerException at
> org.apache.ignite.internal.GridEventConsumeHandler$2$1.run(GridEventConsumeHandler.java:238)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> The reproducer:
> {code:java}
> public class NpeGridEventConsumeHandlerReproducer extends
> GridCommonAbstractTest {
> private static AtomicInteger rmtCounter = new AtomicInteger();
> private static AtomicInteger locCounter = new AtomicInteger();
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return
> super.getConfiguration(igniteInstanceName).setIncludeEventTypes(EVT_CACHE_STOPPED);
> }
> @Test
> public void test() throws Exception {
> startGrids(3);
>
> grid(1).createCache(new CacheConfiguration<>("test_cache"));
> grid(0).events().remoteListen((uuid, evt) ->{
> locCounter.incrementAndGet();
> return true;
> }, evt->{
> rmtCounter.incrementAndGet();
> return true;
> }, EVT_CACHE_STOPPED);
> grid(1).destroyCache("test_cache");
> TimeUnit.SECONDS.sleep(10);
> assertEquals(rmtCounter.get(), locCounter.get());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13106) Java thin client: Race between response and notification for compute tasks
[
https://issues.apache.org/jira/browse/IGNITE-13106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128390#comment-17128390
]
Denis Garus commented on IGNITE-13106:
--
[~alex_pl] LGTM.
Thank you!
> Java thin client: Race between response and notification for compute tasks
> ---
>
> Key: IGNITE-13106
> URL: https://issues.apache.org/jira/browse/IGNITE-13106
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Java thin client {{ClientCompute.execute()}} method can hang due to race
> between processing of COMPUTE_TASK_EXECUTE response and COMPUTE_TASK_FINISHED
> notification.
> These messages are strongly ordered on the server-side. But on the
> client-side response and notification are processed by different threads. If
> notification will be processed before response, task future will never be
> completed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12996) Remote listener of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12996: Assignee: Denis Garus > Remote listener of IgniteEvents has to run inside the Ignite Sandbox. > - > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote listener of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13096) Java thin client: Binary type schema is not registered for nested objects when CompactFooter is enabled
[
https://issues.apache.org/jira/browse/IGNITE-13096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126618#comment-17126618
]
Denis Garus commented on IGNITE-13096:
--
[~alex_pl] looks ok for me.
Thank you!
> Java thin client: Binary type schema is not registered for nested objects
> when CompactFooter is enabled
> ---
>
> Key: IGNITE-13096
> URL: https://issues.apache.org/jira/browse/IGNITE-13096
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we first time marshal object, a binary type registration request is sent
> to the server. This request contains schemas for deserialization
> (deserialization without schema is not possible when CompactFooter is
> enabled). If the object contains references to objects of other types these
> types also sent to the server, but without schemas.
> Reproducer:
> {code:java}
> try (Ignite ignite = Ignition.start(Config.getServerConfiguration())) {
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER)
> .setBinaryConfiguration(new
> BinaryConfiguration().setCompactFooter(true)))
> ) {
> IgniteCache igniteCache =
> ignite.getOrCreateCache(Config.DEFAULT_CACHE_NAME);
> ClientCache clientCache =
> client.getOrCreateCache(Config.DEFAULT_CACHE_NAME);
> Person[] val = new Person[] {new Person(1, "Joe")};
> clientCache.put(1, val);
> assertArrayEquals(val, igniteCache.get(1));
> }
> }
> {code}
> Fails with exception:
> {noformat}
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find
> schema for object with compact footer
> [typeName=org.apache.ignite.client.Person, typeId=1468224522,
> missingSchemaId=970781171, existingSchemaIds=[]]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2028)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:287)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:186)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:793){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Affects Version/s: 2.8.1 > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Affects Versions: 2.8.1 >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Ignite Flags: (was: Docs Required,Release Notes Required) > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13113) CacheEvent#subjectId for cache events with types EventType#EVTS_CACHE
Denis Garus created IGNITE-13113: Summary: CacheEvent#subjectId for cache events with types EventType#EVTS_CACHE Key: IGNITE-13113 URL: https://issues.apache.org/jira/browse/IGNITE-13113 Project: Ignite Issue Type: Bug Components: cache, security Affects Versions: 2.8.1 Reporter: Denis Garus Assignee: Denis Garus For cache events with types: EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED, EVT_CACHE_OBJECT_PUT, EVT_CACHE_OBJECT_READ, EVT_CACHE_OBJECT_REMOVED, EVT_CACHE_OBJECT_LOCKED, EVT_CACHE_OBJECT_UNLOCKED, EVT_CACHE_OBJECT_EXPIRED field CacheEvent#subjectId should be subject id associated with SecuritySubject that trigged the cache event. Currently, CacheEvent#subjectId for these event types is null or equals subject id associated with the node that sends a change request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-13112: - Labels: iep-41 (was: ) > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
[ https://issues.apache.org/jira/browse/IGNITE-13112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-13112: Assignee: Denis Garus > CacheEvent#subjectId is always null for cache events with types > EVT_CACHE_STARTED and EVT_CACHE_STOPPED > --- > > Key: IGNITE-13112 > URL: https://issues.apache.org/jira/browse/IGNITE-13112 > Project: Ignite > Issue Type: Bug > Components: cache, security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > > CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have > fieldCacheEvent#subjectId always null. > CacheEvent#subjectId should be subject id associated with SecuritySubject > that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13112) CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED
Denis Garus created IGNITE-13112: Summary: CacheEvent#subjectId is always null for cache events with types EVT_CACHE_STARTED and EVT_CACHE_STOPPED Key: IGNITE-13112 URL: https://issues.apache.org/jira/browse/IGNITE-13112 Project: Ignite Issue Type: Bug Components: cache, security Reporter: Denis Garus CacheEvents with types EVT_CACHE_STARTED and EVT_CACHE_STARTED have fieldCacheEvent#subjectId always null. CacheEvent#subjectId should be subject id associated with SecuritySubject that trigged the cache event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12343) Remote filter and transformer of ContinuousQueries have to run inside the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17118437#comment-17118437 ] Denis Garus commented on IGNITE-12343: -- [~alex_pl] thank you for reviewing! > Remote filter and transformer of ContinuousQueries have to run inside the > Ignite Sandbox > > > Key: IGNITE-12343 > URL: https://issues.apache.org/jira/browse/IGNITE-12343 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remote filter and transformer of ContinuousQueries have to run on a remote > node inside the Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11712) SQL: review security check for SQL/DML queries
[ https://issues.apache.org/jira/browse/IGNITE-11712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11712: - Labels: (was: iep-41) > SQL: review security check for SQL/DML queries > -- > > Key: IGNITE-11712 > URL: https://issues.apache.org/jira/browse/IGNITE-11712 > Project: Ignite > Issue Type: Improvement > Components: security, sql >Reporter: Roman Kondakov >Priority: Major > > Currently the security check (read/write permissions) is carried out during > the query execution. It involves some extra actions (like a query > registration) which can be avoided if the security check is conducted on the > earlier stage of the query execution, for example right away after the > parsing. > For SELECT queries only read permission should be checked. > For INSERT queries without SELECT only write permission should be checked. > For UPDATE queries or INSERT queries with SELECT both read and write > permissions should be checked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11712) SQL: review security check for SQL/DML queries
[ https://issues.apache.org/jira/browse/IGNITE-11712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-11712: - Component/s: security > SQL: review security check for SQL/DML queries > -- > > Key: IGNITE-11712 > URL: https://issues.apache.org/jira/browse/IGNITE-11712 > Project: Ignite > Issue Type: Improvement > Components: security, sql >Reporter: Roman Kondakov >Priority: Major > Labels: iep-41 > > Currently the security check (read/write permissions) is carried out during > the query execution. It involves some extra actions (like a query > registration) which can be avoided if the security check is conducted on the > earlier stage of the query execution, for example right away after the > parsing. > For SELECT queries only read permission should be checked. > For INSERT queries without SELECT only write permission should be checked. > For UPDATE queries or INSERT queries with SELECT both read and write > permissions should be checked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12589) Remote thin client operations are not authorized correctly.
[ https://issues.apache.org/jira/browse/IGNITE-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12589: Assignee: (was: Denis Garus) > Remote thin client operations are not authorized correctly. > --- > > Key: IGNITE-12589 > URL: https://issues.apache.org/jira/browse/IGNITE-12589 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Mikhail Petrov >Priority: Major > Labels: iep-41 > > In the current Ignite security approach security subject id is considered to > be a node id (see IgniteSecurityProcessor#withContext()). In the case of thin > clients, this approach doesn't work correctly. If some operation is executed > on behalf of the thin client on a remote node (node that is different from > one to which thin client connection was established), it's impossible in the > same way as for a node to obtain a thin client security subject information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12996) Remote listener of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12996: Assignee: (was: Denis Garus) > Remote listener of IgniteEvents has to run inside the Ignite Sandbox. > - > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Priority: Major > Labels: iep-38 > > Remote listener of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12996) Remote listener of IgniteEvents has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12996: Assignee: Denis Garus > Remote listener of IgniteEvents has to run inside the Ignite Sandbox. > - > > Key: IGNITE-12996 > URL: https://issues.apache.org/jira/browse/IGNITE-12996 > Project: Ignite > Issue Type: Task > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote listener of IgniteEvents has to run on a remote node inside the Ignite > Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13010) A local listener for cache events with type EVT_CACHE_STOPPED does not get a cache event from a remote node.
Denis Garus created IGNITE-13010:
Summary: A local listener for cache events with type
EVT_CACHE_STOPPED does not get a cache event from a remote node.
Key: IGNITE-13010
URL: https://issues.apache.org/jira/browse/IGNITE-13010
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Denis Garus
A local listener for cache events with type EVT_CACHE_STOPPED does not get a
cache event from a remote node.
That occurs due to NPE on a remote node:
{code:java}
[2020-05-14
12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
Failed to send event notification to node:
55671ec1-dad9-452b-8ab2-4b7916c0[2020-05-14
12:07:25,623][ERROR][sys-#206%security.NpeGridEventConsumeHandlerReproducer2%][GridEventConsumeHandler]
Failed to send event notification to node:
55671ec1-dad9-452b-8ab2-4b7916c0java.lang.NullPointerException at
org.apache.ignite.internal.GridEventConsumeHandler$2$1.run(GridEventConsumeHandler.java:238)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
The reproducer:
{code:java}
public class NpeGridEventConsumeHandlerReproducer extends
GridCommonAbstractTest {
private static AtomicInteger rmtCounter = new AtomicInteger();
private static AtomicInteger locCounter = new AtomicInteger();
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return
super.getConfiguration(igniteInstanceName).setIncludeEventTypes(EVT_CACHE_STOPPED);
}
@Test
public void test() throws Exception {
startGrids(3);
grid(1).createCache(new CacheConfiguration<>("test_cache"));
grid(0).events().remoteListen((uuid, evt) ->{
locCounter.incrementAndGet();
return true;
}, evt->{
rmtCounter.incrementAndGet();
return true;
}, EVT_CACHE_STOPPED);
grid(1).destroyCache("test_cache");
TimeUnit.SECONDS.sleep(10);
assertEquals(rmtCounter.get(), locCounter.get());
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12579) JDBC SQL INSERT operation hangs with security enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17105157#comment-17105157
]
Denis Garus commented on IGNITE-12579:
--
[~PetrovMikhail] LGTM
> JDBC SQL INSERT operation hangs with security enabled.
> --
>
> Key: IGNITE-12579
> URL: https://issues.apache.org/jira/browse/IGNITE-12579
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: iep-41
> Attachments: JdbcRemoteKeyInsertTest.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> SQL INSERT operation hangs in case INSERT KEY belongs to remote node(node
> that is different from one to which jdbc connection was established) and
> security enabled with the following exception in log:
> {code:java}
> [2020-01-24
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]][2020-01-24
> 14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1470)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)[2020-01-24 14:59:42,198][WARN
> ][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][CacheDiagnosticManager]
> Page locks dump:
> Thread=[name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1%, id=116],
> state=WAITINGLocked pages = []Locked pages log:
> name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 2020-01-24
> 14:59:42.194)Thread=[name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1%,
> id=135], state=TIMED_WAITINGLocked pages = []Locked pages log:
> name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1%
> time=(1579867182194, 2020-01-24
> 14:59:42.194)Thread=[name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1%,
> id=126], state=WAITINGLocked pages = []Locked pages log:
> name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1%
> time=(1579867182194, 2020-01-24
> 14:59:42.194)Thread=[name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1%,
> id=117], state=TIMED_WAITINGLocked pages = []Locked pages log:
> name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194,
> 2020-01-24 14:59:42.194)Thread=[name=main, id=1], state=TIMED_WAITINGLocked
> pages = []Locked pages log: name=main time=(1579867182193, 2020-01-24
> 14:59:42.193)
> [2020-01-24
> 14:59:42,198][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][G]
> Failed to execute runnable.java.lang.NullPointerException at
> org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
> at
>
[jira] [Created] (IGNITE-12996) Remote listener of IgniteEvents has to run inside the Ignite Sandbox.
Denis Garus created IGNITE-12996: Summary: Remote listener of IgniteEvents has to run inside the Ignite Sandbox. Key: IGNITE-12996 URL: https://issues.apache.org/jira/browse/IGNITE-12996 Project: Ignite Issue Type: Task Components: security Reporter: Denis Garus Remote listener of IgniteEvents has to run on a remote node inside the Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12983) Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID)
Denis Garus created IGNITE-12983: Summary: Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID) Key: IGNITE-12983 URL: https://issues.apache.org/jira/browse/IGNITE-12983 Project: Ignite Issue Type: Improvement Reporter: Denis Garus Assignee: Denis Garus Fix For: 2.9 We should write down to log all exception inside IgniteSecurityProcessor#withContext(java.util.UUID). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12345) Remote listener of IgniteMessaging has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096505#comment-17096505 ] Denis Garus commented on IGNITE-12345: -- [~alex_pl] thank you for review! > Remote listener of IgniteMessaging has to run inside the Ignite Sandbox. > > > Key: IGNITE-12345 > URL: https://issues.apache.org/jira/browse/IGNITE-12345 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Remote listener of IgniteMessaging has to run on a remote node inside the > Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12345) Remote listener of IgniteMessaging has to run inside the Ignite Sandbox.
[ https://issues.apache.org/jira/browse/IGNITE-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12345: - Release Note: A remote listener of IgniteMessaging runs on a remote node inside the Ignite Sandbox if it is turned on. > Remote listener of IgniteMessaging has to run inside the Ignite Sandbox. > > > Key: IGNITE-12345 > URL: https://issues.apache.org/jira/browse/IGNITE-12345 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Remote listener of IgniteMessaging has to run on a remote node inside the > Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12283) Getting proxied components of Ignite through the Ignition interface inside the sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12283: - Release Note: A user-defined code gets a proxied instance of Ignite that allows users to use public API of Ignite inside the sandbox. > Getting proxied components of Ignite through the Ignition interface inside > the sandbox > -- > > Key: IGNITE-12283 > URL: https://issues.apache.org/jira/browse/IGNITE-12283 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > IgniteKernal allows a user-defined code to get access to the internal > features of Ignite. That behavior leads to security lack. > We must encapsulate _IgniteKernal_ to restrict access to it from > user-defined code. > Additionally, a proxied instance of Ignite allows users to use public API of > Ignite. Otherwise, using public API inside the sandbox without proxying can > be the reason for access control errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12283) Getting proxied components of Ignite through the Ignition interface inside the sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12283: - Summary: Getting proxied components of Ignite through the Ignition interface inside the sandbox (was: Access restriction to IgniteKernal) > Getting proxied components of Ignite through the Ignition interface inside > the sandbox > -- > > Key: IGNITE-12283 > URL: https://issues.apache.org/jira/browse/IGNITE-12283 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > IgniteKernal allows a user-defined code to get access to the internal > features of Ignite. That behavior leads to security lack. > We must encapsulate _IgniteKernal_ to restrict access to it from > user-defined code. > Additionally, a proxied instance of Ignite allows users to use public API of > Ignite. Otherwise, using public API inside the sandbox without proxying can > be the reason for access control errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12283) Access restriction to IgniteKernal
[ https://issues.apache.org/jira/browse/IGNITE-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12283: - Description: IgniteKernal allows a user-defined code to get access to the internal features of Ignite. That behavior leads to security lack. We must encapsulate _IgniteKernal_ to restrict access to it from user-defined code. Additionally, a proxied instance of Ignite allows users to use public API of Ignite. Otherwise, using public API inside the sandbox without proxying can be the reason for access control errors. was: IgniteKernal allows a user-defined code to get access to the internal features of Ignite. That behavior leads to security lack. We must encapsulate _IgniteKernal_ to restrict access to it from user-defined code. > Access restriction to IgniteKernal > -- > > Key: IGNITE-12283 > URL: https://issues.apache.org/jira/browse/IGNITE-12283 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 10m > Remaining Estimate: 0h > > IgniteKernal allows a user-defined code to get access to the internal > features of Ignite. That behavior leads to security lack. > We must encapsulate _IgniteKernal_ to restrict access to it from > user-defined code. > Additionally, a proxied instance of Ignite allows users to use public API of > Ignite. Otherwise, using public API inside the sandbox without proxying can > be the reason for access control errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12589) Remote thin client operations are not authorized correctly.
[ https://issues.apache.org/jira/browse/IGNITE-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12589: Assignee: Denis Garus > Remote thin client operations are not authorized correctly. > --- > > Key: IGNITE-12589 > URL: https://issues.apache.org/jira/browse/IGNITE-12589 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: Mikhail Petrov >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > In the current Ignite security approach security subject id is considered to > be a node id (see IgniteSecurityProcessor#withContext()). In the case of thin > clients, this approach doesn't work correctly. If some operation is executed > on behalf of the thin client on a remote node (node that is different from > one to which thin client connection was established), it's impossible in the > same way as for a node to obtain a thin client security subject information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get a security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12904: Assignee: Denis Garus > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get a security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12759) Getting a SecurityContext from GridSecurityProcessor
[ https://issues.apache.org/jira/browse/IGNITE-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12759: - Release Note: The GridSecurityProcessor interface was extended by adding the securityContext(UUID subjId) method. This method should be used to get the security context by a security subject id. > Getting a SecurityContext from GridSecurityProcessor > > > Key: IGNITE-12759 > URL: https://issues.apache.org/jira/browse/IGNITE-12759 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Fix For: 2.8.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID > subjId)_ method and use this method to get the actual security context. > h4. Backward compatibility > The logic of getting security context for Ignite: > # Try to get a security context using _ClusterNode_ attributes (as it works > now); > # Get a security context through _GridSecurityProcessor_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Labels: iep-41 (was: ) > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Priority: Major > Labels: iep-41 > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get a security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Component/s: security > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Priority: Major > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get a security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Description: We should add method IgniteSecurity#securityContext(UUID subjId) to allow users to get security subject info. > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Priority: Major > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Description: We should add method IgniteSecurity#securityContext(UUID subjId) to allow users to get a security subject info. (was: We should add method IgniteSecurity#securityContext(UUID subjId) to allow users to get security subject info.) > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Priority: Major > > We should add method IgniteSecurity#securityContext(UUID subjId) to allow > users to get a security subject info. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12904) Add method IgniteSecurity#securityContext(UUID subjId)
[ https://issues.apache.org/jira/browse/IGNITE-12904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12904: - Summary: Add method IgniteSecurity#securityContext(UUID subjId) (was: ШптшеуЫусгкшен) > Add method IgniteSecurity#securityContext(UUID subjId) > -- > > Key: IGNITE-12904 > URL: https://issues.apache.org/jira/browse/IGNITE-12904 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12904) ШптшеуЫусгкшен
Denis Garus created IGNITE-12904: Summary: ШптшеуЫусгкшен Key: IGNITE-12904 URL: https://issues.apache.org/jira/browse/IGNITE-12904 Project: Ignite Issue Type: Improvement Reporter: Denis Garus -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12781) Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request sometimes.
[ https://issues.apache.org/jira/browse/IGNITE-12781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12781: Assignee: (was: Denis Garus) > Cache_Put event generated from a remote_client user action has subject uuid > of Node that executes the request sometimes. > > > Key: IGNITE-12781 > URL: https://issues.apache.org/jira/browse/IGNITE-12781 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.8 >Reporter: Veena Mithare >Priority: Major > Labels: iep-41 > > Unable to get the right audit information i.e. we are unable > to get the right subject for users logged in through dbeaver ( jdbc thin > client. ). > > This is because the subjectid associated with the "CACHE_PUT" > event when an update is triggered by the jdbc thin client, contains the uuid > of the node that executed the update rather than the logged in jdbc thin > client user. > This was discussed in the 'Ignite users' group > [http://apache-ignite-users.70518.x6.nabble.com/JDBC-thin-client-incorrect-security-context-td31354.html] > During the update through jdbc client, there > could be 2 kinds of threads acting on it. The 'client-connector' thread and > the 'sys-stripe'. If the client-connector thread completes the transaction > and calls the record, it is able to send a 'cache_put' event with the uuid > of the person logged in to through the jdbc thin client . Whereas if the > 'sys-stripe' thread completes the transaction, it sends the 'cache_put' > event with the node uuid. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12343) Remote filter and transformer of ContinuousQueries have to run inside the Ignite Sandbox
[ https://issues.apache.org/jira/browse/IGNITE-12343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus reassigned IGNITE-12343: Assignee: Denis Garus > Remote filter and transformer of ContinuousQueries have to run inside the > Ignite Sandbox > > > Key: IGNITE-12343 > URL: https://issues.apache.org/jira/browse/IGNITE-12343 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > Remote filter and transformer of ContinuousQueries have to run on a remote > node inside the Ignite Sandbox if it is turned on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12500) IgniteProxy should be injected into non-system types only.
[ https://issues.apache.org/jira/browse/IGNITE-12500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17082229#comment-17082229 ] Denis Garus commented on IGNITE-12500: -- Resolved inside IGNITE-12342. > IgniteProxy should be injected into non-system types only. > -- > > Key: IGNITE-12500 > URL: https://issues.apache.org/jira/browse/IGNITE-12500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector > should inject an IgniteProxy into non-system types only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12500) IgniteProxy should be injected into non-system types only.
[ https://issues.apache.org/jira/browse/IGNITE-12500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12500: - Ignite Flags: (was: Docs Required,Release Notes Required) > IgniteProxy should be injected into non-system types only. > -- > > Key: IGNITE-12500 > URL: https://issues.apache.org/jira/browse/IGNITE-12500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector > should inject an IgniteProxy into non-system types only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12500) IgniteProxy should be injected into non-system types only.
[ https://issues.apache.org/jira/browse/IGNITE-12500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus resolved IGNITE-12500. -- Resolution: Fixed > IgniteProxy should be injected into non-system types only. > -- > > Key: IGNITE-12500 > URL: https://issues.apache.org/jira/browse/IGNITE-12500 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > > When the Ignite Sandbox is enabled, the GridResourceProxiedIgniteInjector > should inject an IgniteProxy into non-system types only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
