[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15322:
---
Labels: important ise (was: ise)
> 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: important, 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)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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.
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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.
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).
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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 optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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 SecurityAwareJob 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.
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).
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15322:
-
Fix Version/s: 2.15
> 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 20m
> 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 optionsl interface that compute job can
> implement.
> {code:java}
> /** */
> public interface SecurityAwareJob {
> /** */
> 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 by
> explicitly specified permissions|
> By the way the SecurityAwareJob 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)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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 optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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 by explicitly
specified permissions|
By the way the SecurityAwareJob 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.
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).
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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 optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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 unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
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.
For
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteCompute internalCompute();
/** */
public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteCompute internalCompute();
/** */
public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that compute job can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteCompute internalCompute();
/** */
public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityAwareJob {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteCompute internalCompute();
/** */
public IgniteCompute internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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 by explicitly
specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware 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|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by task name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by specified permissions|auth skipped|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by task name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by specified permissions|auth by specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC task|auth by specified permissions|auth by specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
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)
Examples of SYSTEM public tasks -
- Visor tasks on which the user control script is implemented
- JDBC tasks
All of them 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 SecurityPermissionAware interface described above.
||X||Public API||Private API||
|PUBLIC task|auth by task name|auth by name|
|SYSTEM INTERNAL task|restricted|auth skipped|
|SYSTEM PUBLIC|auth by specified permissions|auth by specified permissions|
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 tasks are authorized by the name of the SYSTEM wrapper
task. We should decide how to properly fix their authorization.
3. We must decide what permissions are required for Visor tasks.
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).
Possible 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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 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.
For Ignite node API we can provide dedicated methods to obtain internal version
of compute instances in IgniteEx and force developers to use them for any
internal means.
{code:java}
public interface IgniteEx extends Ignite {
/** */
public IgniteComputeImpl internalCompute();
/** */
public IgniteComputeImpl internalCompute(ClusterGroup grp);
}
{code}
The first two steps give us the ability to
A. safely skip authorization of SYSTEM tasks which are
called through INTERNAL API unless permissions are specified explicitly (see
clause 3).
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. This helps to skip sending task execution requests between nodes if
the user does not have permission to execute the task.
It can be solved by introducing optionsl interface that any task executable can
implement.
{code:java}
/** */
public interface SecurityPermissionAware {
/** */
public SecurityPermissionSet requiredPermissions();
}
{code}
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 tasks execution is authorized by the name of the SYSTEM
wrapper task. We should decide how to properly fix their authorization.
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).
Possible 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.
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov 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 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.
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).
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.
> 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
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).
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.
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).
> 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).
> 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
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15322:
---
Labels: ise (was: )
> 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15322) System tasks should run without any explicitly granted permissions
[
https://issues.apache.org/jira/browse/IGNITE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kazakov updated IGNITE-15322:
--
Issue Type: Bug (was: Improvement)
> 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
>Priority: Minor
>
> 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).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
