Ability for non-admins to create tags

Bug #1889467 reported by Ramon Grullon on 2020-07-29
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Wishlist
Unassigned

Bug Description

MAAS 2.8
Ubuntu 18.04 LTS

Currently based on the api documentation when setting a tag -
POST /MAAS/api/2.0/tags/{name}/?op=update_nodes

You will get a 403 error as regular user -

HTTP Status Code : 403

Content

Must be a superuser or supply a rack_controller.

There is a case to be made that this ability should not be an administrative tasks only and should be allowed as a non-administrative tasks for regular users.

From customer -

Then please consider this an RFE. Setting tags should not be restricted to administrators (I can see an argument for *creating* tags being administrative). Consider this example use case. MAAS user/roles PSB, MORPHEUS, ADMIN. Both PSB and MORPHEUS are, themselves, infrastructure management systems which parcel systems out to end users. Ideally, neither PSB nor MORPHEUS should be able to take over each others systems (so should NOT be administrators). But if they aren't administrators, they can't use the tagging system (e;g. to mark a machine as needing non-MAAS remediation (see our cases about Dell BOSS, MAAS deficiencies in sanitizing NVMe, DELL BOSS, Dell/Samsung SSD), etc). Tags may well be used for a wide variety of purposes, and non-administrative users being barred from assigning a tag to a system it "owns" makes either tags, or the non-administrative facility useless in our context.

Similarly, for setting storage ... having allocated a machine to "PSB" why should PSB not be able to configure the desired storage?

This is not an exhaustive list .. but it seems to us that non-administrative roles are overly constrained. I suppose for compatibility purposes this would mean either a recasting (a generic, perhaps bitflag controlled (this feature on, that feature off) with the default non-administrative roles to be locked down as they are now, or a third kind of role). To a first approximation what we expected/require is that the non-administrative roles can't change MAAS itself, nor should they be able to see or manipulate systems that are allocated to other users. No other limitations on what these users can do ...

With the current setup, this means all users are administrative ... which means there are no protections against one user/role taking over systems that are in use by others (which is unfortunate, to say the least).

Tags: sts Edit Tag help
tags: added: sts
Dougal Matthews (d0ugal) on 2020-10-12
Changed in maas:
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers