Add sync-permissions-by-tags script to share resources across client projects

[TDianaAle]

What

This adds sync-permissions-by-tags.gmp.py, a script that automates sharing scan resources between users, so an analyst can work on several client projects at once while holding only the permissions they actually need.

Tags are already how resources get labelled in the web UI, so they become the source of truth. An administrator tags a resource project:Acme, and the analysts working on that client join the Acme group. The script then keeps the permissions in sync with the tags:

1. Discovers all scanners, tasks and reports carrying a project:* tag
2. Ensures a group exists for each project found
3. Grants each group the minimum permissions on its own resources
4. Optionally revokes permissions whose tag was removed or whose resource was deleted

Resource type	Permissions granted	What the analyst can do
Scanner	get_scanners	see the scanner the task runs on
Task	get_tasks, start_task, stop_task	see and control the client's scans
Report	get_reports	read the client's findings

Resources without a project:* tag are never touched, and re-runs are idempotent: existing permissions are detected and skipped. An analyst in two groups sees both clients' resources, and nothing else.

Usage

gvm-script --gmp-username admin --gmp-password secret \
    socket sync-permissions-by-tags.gmp.py

# preview without writing
gvm-script ... sync-permissions-by-tags.gmp.py --dry-run

# also revoke orphaned permissions
gvm-script ... sync-permissions-by-tags.gmp.py --cleanup

# inventory only: show every resource and its tags
gvm-script ... sync-permissions-by-tags.gmp.py --all

How the changes were verified

Exercised end to end against a container deployment of Greenbone Community Edition 22.4 (gvmd 26.36.1, DB revision 281): resource discovery, group creation, permission granting, untagged resources left alone, idempotent re-runs, --dry-run performing no writes, and garbage collection revoking only the permissions whose tag was removed.

Inventory mode shows which resources are in scope, and which are not:

== TASKS ==
  Found 3 task(s)
  [SYNC] gvmsync-task-alpha  id=5a350072-...  owner=admin  tags=project:ClientA
  [SYNC] gvmsync-task-beta   id=ff2f185e-...  owner=admin  tags=project:ClientB
  [----] gvmsync-task-untagged  id=ea3d34a9-...  owner=admin  (no tags)

A sync run. ClientA already holds its permissions from an earlier run and is left alone; ClientB has just been tagged and receives exactly what it needs:

--- Phase 1: Resource extraction ---
  Extracting scanners with project:* tags...
    1/2 scanner(s) tagged
  Extracting tasks with project:* tags...
    2/3 task(s) tagged
  Extracting reports with project:* tags...
    1/1 report(s) tagged
  Discovered 2 project(s)

--- Phase 3: Permission configuration ---

  Project: ClientA

  Project: ClientB
    Granted 'get_tasks' on 'gvmsync-task-beta'
    Granted 'start_task' on 'gvmsync-task-beta'
    Granted 'stop_task' on 'gvmsync-task-beta'

--- Summary ---
Projects: 2 | Permissions: 3 | Time: 0.19s

Garbage collection after the project:ClientB tag was removed from that task. Only the permissions that lost their tag are revoked; ClientA's five are untouched:

--- Phase 4: Garbage collection ---
  Checking group 'ClientA'...
  Checking group 'ClientB'...
    Removed 'get_tasks' from 'gvmsync-task-beta'
    Removed 'start_task' from 'gvmsync-task-beta'
    Removed 'stop_task' from 'gvmsync-task-beta'
  Cleanup: scanned=8, removed=3

Implementation notes

• Self-contained, no dependencies beyond python-gvm
• SPDX header, GPL-3.0-or-later, ruff format and ruff check clean at 80 columns
• Added to scripts/README.md in the documented format
• Flags are read by combining args.script_args with the positional list, following the approach in certbund-report.gmp.py, since gvm-script declares scriptargs with nargs="*" and leaves --prefixed arguments to parse_known_args(). Unsupported arguments are rejected rather than ignored, so a mistyped flag cannot be silently treated as a real run

Why

A security analyst is typically assigned to more than one client at a time. For each of them, the analyst needs to see that client's tasks and reports — start and stop their scans, read their findings — and nothing belonging to anyone else.

Greenbone Community Edition has no built-in way to express this. Setting it up by hand means, for every client: create a group, add the analysts to it, then grant each permission on each resource one at a time — get_tasks, start_task and stop_task on every task, get_scanners on the scanner, get_reports on every report. Adding one task to a client means repeating the grants. Moving an analyst to another project means redoing it from scratch. And when a resource stops belonging to a client, the old permissions stay behind unless someone remembers to remove them, silently leaving access in place.

References

None.

[github-actions]

Conventional Commits Report

Type	Number
Added	1

🚀 Conventional commits found.