...

Motivation

...

The main unit of the Ignite Sandbox is the IgniteSandbox interface, accessed through IgniteSecurity.
Users for this interface are components that can run a user-defined code. To run a user-defined code with restrictions,
they have to pass it to the IgniteSandbox.execute method.

There are two a few conditions to run user-defined code with restrictions:

• installed GridSecurityProcessor;
• GridSecurityProcessor#sandboxEnabled == true;
• installed SecurityManager.

...

A user-defined code should have the opportunity of using the public API of Ignite on a remote node.
But he may don't have some permissions to execute this operation successfully. For example, to put a value into a cache,
it requires permissions for accessing to reflection API and reading system property IGNITE_ALLOW_ATOMIC_OPS_IN_TX.
In that case, we have to use AccessController.doPrirvelged without AccessControlContext call to exclude a user-defined code from checking of permissions.Utils SecurityUtils.doPriveleged method does calling AccessController.doPrirvelged a more convenient way

We can achieve that behavior by using a proxy of interface Ignite that executes methods inside a privileged block. Builder methods of Ignite proxy create a proxy of public interfaces (IgniteCache, IgniteCompute, and so on) that run their methods inside a privileged block too.
Additionally, using of Ignite proxy allows restricting access of a user-defined code to internal Ignite classes.

Phase 1.

1. Create implementations of the IgniteSandbox interface.
2. Extend interface IgniteSecurity to use IgniteSandbox.
3. Extend interface SecuritySubject to get sandbox permissions.
4. Execution a user-defined code in the Ignite Sandbox for the following components:
   a. ComputeJob;
   b. EntryProcessor;
   c. IgniteBiPredicate;
   d. IgniteClosure;
   e. StreamReceiver.

...

1. Restrict access a user-defined code to internal API of Ignite:
   a. Restrict internal package access;
   b. Encapsulation of IgniteKernal.
2. Execution a user-defined code in the Ignite Sandbox for the following features:
   a. Continuous Queries;
   b. IgniteMassaging;
   c. ServiceGridIgniteEvents.

Risks and Assumptions

The existing implementations of interfaces Runnable, IgniteRunnable,
Callable.class, IgniteCallable, ComputeTask, ComputeJob, IgniteClosure, IgniteBiClosure, IgniteDataStreamer, IgnitePredicate,
IgniteBiPredicate cannot cast the instance of Ignite to IgniteEx or IgniteKernal if the Sandbox is enabled.// 

Discussion Links

http://apache-ignite-developers.2346864.n4.nabble.com/Review-needed-for-IGNITE-11410-Sandbox-for-user-defined-code-td43955.html

...