I’m experiencing a permission issue in Greenbone Community 24.10:
Users can start/stop their own tasks without problems.
Tasks, scanners, and reports are shared within a group using tags and group-based permissions.
When a user tries to start or stop a task owned by another user within the same group, they receive:
Permission denied
Assigning explicit permissions for the resource to the user does not solve the issue.
We do not want to grant Super Permissions for security reasons; we want normal users to manage shared resources without giving global privileges.
Expected behavior:
Users belonging to a group with shared resources (tasks, scanners, reports) should be able to start and stop tasks owned by other group members, respecting the resource-level permissions.
Notes / Workarounds tried:
Shared resources via tags and group permissions.
Explicit resource permission assigned directly to the user.
Using Super Permissions works, but is not an acceptable solution for security.
Question:
Is the current behavior intended by design, or is there a way to allow start/stop on shared tasks without granting Super Permissions?
I have done some work to look into your previous question regarding creating specific permission profiles using Role objects. I have some progress but I have not found time to present the solution into a formatted answer yet.
However, it appears you have also achieved some progress. Can you describe your current setup for sharing resource permissions among users so I can share your vantage point. There may be more than one possible way to accomplish what you are doing and I want to ensure that readers of this question can be on the same page as you.
Since the previous question i’ve change my mind a bit and tried different ways.
Here is my current setup in short:
Roles are used only as a container for global permissions.
Resource sharing is done exclusively via resource permissions assigned to Groups.
Users are members of groups, and tasks/scanners/reports are shared to those groups via explicit resource permissions.
This works correctly for scanners and reports.
For tasks, permissions are assigned successfully (via GUI and GMP API), and the UI reflects this correctly (start/stop buttons become visible). However, when a user tries to start or stop a task owned by another user, the action fails with “Permission denied”, even though:
both users are in the same group,
the group has the required task resource permissions,
the user has the required global permissions via role.
Users can always start/stop their own tasks without issues.
At this point I’m trying to understand whether this behavior is intended by design for task execution, or if there is an additional constraint I’m missing.
I haven’t had much time to look into it. But here is a paraphrase of what I was told by a developer:
You have three accounts 1,2 and 3. He wants 3 to have access to everything 1 and 2 have, but 1 and 2 should not have access to each other. First they all must have a suitable role. That’s Admin. They also need to be owned by a common Admin. The common Admin then goes into their User List, opens the detailed view and gives get_user Permission for account3 to account 1 and 2. Account 1 and 2 can now login, go to each Task they want 3 to handle and create a write permission to it for Account 3.
