[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15322:
---------------------------------------
Release Note: Granting permissions to system compute tasks by their FQN has
been replaced with predefined system permissions
> System tasks should run without any explicitly granted permissions
> ------------------------------------------------------------------
>
> Key: IGNITE-15322
> URL: https://issues.apache.org/jira/browse/IGNITE-15322
> Project: Ignite
> Issue Type: Bug
> Components: compute, security
> Reporter: Ilya Kazakov
> Assignee: Mikhail Petrov
> Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> For example, this code needs TASK_EXECUTE permissions.
> {code:java}
> Affinity affinity = ignite.affinity("TEST");
> affinity.mapKeysToNodes(Arrays.asList(1L,100L, 1000L));{code}
> This is unexpected behavior, because:
> - the task started implicitly (under the hood), customer should not to know
> about it.
> - this is a system task (not defined by a customer), the tasks needs for a
> normal grid workflow.
> Also, I suppose there are any other implicitly tasks, which could lead to
> unexpected behavior (need permissions).
> Proposed way to solve this issue:
> 1. Add mechanism to destinguish whether task class is SYSTEM (part of the
> Ignite codebase) or USER.
> Here we can reuse SecurityUtils#isSystemType mechanism that is used in Ignite
> Sanbox implementation.
> 2. Add mechanism to detect if task execution was initiated by the user
> (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
> It seems that the easiest way to achieve this is to completely separate the
> public and private Compute APIs.
> Task executioin requests received through Ignite Thin Clients are considered
> PUBLIC CALLs.
> The first two steps give us the ability to
> A. safely skip authorization of SYSTEM tasks which are
> called through INTERNAL API.
> B. keep authorization of PUBLIC tasks intact
> C. prevent users of calling SYSTEM tasks directly through PUBLIC API ( it
> means that all user task execution requests received through REST or Thin
> client protocols MUST be executed through PUBLIC API).
> 3. Add the ability to explicitly specify for SYSTEM
> task/callable/runnable/closure what permission should be checked before its
> execution.
> It can be solved by introducing optional interface that compute job can
> implement.
> {code:java}
> /** */
> public interface PublicAccessJob {
> /** */
> public SecurityPermissionSet requiredPermissions();
> }
> {code}
> 4. SYSTEM tasks can splitted into two categories -
> SYSTEM INTERNAL (tasks that are not available to the user) and SYSTEM PUBLIC
> tasks (tasks that are part oof the ignite code but are available to the user
> and can be executed through the PUBLIC API)
> Example of SYSTEM public tasks - Visor tasks on which the user control script
> is implemented
> They are executed through Thin Client which is considered Public API.
> Considering that SYSTEM PUBLIC tasks can potentially be executed by the user,
> we must force the developer to explicitly specify permissions for tasks of
> this type. It can be done by checking that SYSTEM tasks that are executed
> through PUBLIC API impelements PublicAwareJob interface described above.
> ||X||Public API||Private API||
> |PUBLIC task|auth by task name|restricted|
> |SYSTEM INTERNAL task|restricted|auth skipped|
> |SYSTEM PUBLIC task|auth by explicitly specified permissions|auth skipped|
> By the way the PublicAccessJob interface, implemented by all Visor jobs,
> allows you to specify for each specific Visor job what permissions it
> requires. Also it is proposed to guard all Visor Jobs with ADMIN_OPS
> permission by default.
> 5. Authorization of SYSTEM tasks cancellation must be skipped it they are
> canceled by the same user who started them, oterwise dedicated permissions is
> required (e.g. ADMIN_KILL). USER tasks cancellation is performed by their
> names.
> Possible troubles:
> 1. Mentioned SecurityUtils#isSystemType works only for the ignite-core
> module. If some tasks are defined inside other Ignite modules - they will not
> be considered SYSTEM. Currently there are no such task.
> 2. Currently all DotNet code is wrapped and executed via special SYSTEM
> tasks. As a result all DotNet runnable/callable/tasks are authorized by the
> name of the SYSTEM wrapper task. So if TASK_EXECUTE permissions for the
> SYSTEM wrapper task is granted - user can execute whathever DotNet custom tas
> he wants. After the propsed changes SYTEM task authorization will no more.be
> performed. So DotNet custom code execution will become completeley
> unauthorised. We should fix it in a separate ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
