[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15322:
------------------------------------
Description:
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).
Possible lan 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.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
3. Add ability to explicitly specify for SYSTEM task/callable/runnable/closure
what permission should be checked before its execution.
4. Skip permission check for the tasks that are SYSTEM and initiated by the
Ignite internal code unless permissions are specified explicitly.
5. Restrict execution of SYSTEM tasks initiated by the user directly and for
which no explicit permissions are specified.
Possible troubles:
1. We have control.sh tasks that are executed via the thin client. Task
execution through the thin client compute is considered as PUBLIC CALL so we
should assign some permission to each control.sh task.
To skip creation of a separate permissions for each control.sh task it is
proposed to group tasks that belongs to the same control.sh command e.g.
control.sh --cache ... tasks will require ADMIN_CACHE permission
control.sh --tx ... tasks will require ADMIN_TX permission
2. 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.
was:
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).
Plan 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.
2. Add mechanism to detect if task execution was initiated by the user (PUBLIC
CALL) or by the Ignite system itself (INTERNAL CALL).
3. Add ability to explicitly specify for SYSTEM task/callable/runnable/closure
what permission should be checked before its execution.
4. Skip permission check for the tasks that are SYSTEM and initiated by the
Ignite internal code unless permissions are specified explicitly.
5. Restrict execution of SYSTEM tasks initiated by the user directly and for
which no explicit permissions are specified.
Possible troubles:
1. We have control.sh tasks that are executed via the thin client. Task
execution through the thin client compute is considered as PUBLIC CALL so we
should assign some permission to each control.sh task.
To skip creation of a separate permissions for each control.sh task it is
proposed to group tasks that belongs to the same control.sh command e.g.
control.sh --cache ... tasks will require ADMIN_CACHE permission
control.sh --tx ... tasks will require ADMIN_TX permission
2. 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.
> 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
> Time Spent: 10m
> 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).
> Possible lan 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.
> 2. Add mechanism to detect if task execution was initiated by the user
> (PUBLIC CALL) or by the Ignite system itself (INTERNAL CALL).
> 3. Add ability to explicitly specify for SYSTEM
> task/callable/runnable/closure what permission should be checked before its
> execution.
> 4. Skip permission check for the tasks that are SYSTEM and initiated by the
> Ignite internal code unless permissions are specified explicitly.
> 5. Restrict execution of SYSTEM tasks initiated by the user directly and for
> which no explicit permissions are specified.
> Possible troubles:
> 1. We have control.sh tasks that are executed via the thin client. Task
> execution through the thin client compute is considered as PUBLIC CALL so we
> should assign some permission to each control.sh task.
> To skip creation of a separate permissions for each control.sh task it is
> proposed to group tasks that belongs to the same control.sh command e.g.
> control.sh --cache ... tasks will require ADMIN_CACHE permission
> control.sh --tx ... tasks will require ADMIN_TX permission
> 2. 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
