Skip to content

Permission Guardrails

Managing permissions is itself a permission, and Magento does not police it. Any admin who may edit roles can tick every box in the resource tree, assign the result to themselves, and log back in with it. Advanced Admin Permissions closes that with four rules, checked at the moment of the write rather than in the form, so the REST and SOAP APIs and any future screen are covered too.

Rule 1: Nobody Edits Their Own Access

Your own role assignments, your own scope restriction and the expiry on one of your own grants are refused, whether the change would widen your access or narrow it. That holds through the user edit form, through the mass actions on the users grid, and through anything else that reaches the same writes.

A save that changes nothing is not a change, so you can still edit the rest of your own account: your name, email, password and interface locale all save normally as long as you leave your access alone.

This is also why the Assign a role and Remove a role mass actions skip your own account, including under Select All.

Rule 2: Nobody Hands Out What They Do Not Hold

A role can only be granted to an admin user or an integration if the acting admin is allowed every resource that role allows. A role can only be given resources its editor holds. Together those stop an admin minting a role that reaches further than they do and then assigning it.

Rule 2 covers every route that grants a role, including the role's Role Users tab. Adding a user there only assigns the role and does not change the user's account, so it is judged as a grant under this rule rather than under Rule 3.

Three consequences worth spelling out:

  • Turning a negative (deny) role back into an ordinary role counts as a grant. That is what stops an admin lifting a denial that applies to them.
  • A restricted admin cannot lift a scope restriction for anyone else, nor allow a website or store view they cannot reach themselves.
  • Assigning a negative (deny) role needs no held resources. A negative role only takes access away, so an admin can assign one without holding the resources it denies.

Rule 3: Nobody Takes Over an Account That Can Do More

Handing out only what you hold means nothing if you can simply take over an account that holds more. User management lets an admin set any colleague's password and email address, and whoever can do that can sign in as that colleague.

So an admin may only change, delete or unlock an account whose every role they could grant themselves. An account holding a role beyond the acting admin's reach is refused, with a message naming the account it would not let them change.

The check sits on the admin user resource model, so every route to the same write meets it:

  • The user edit form and the Delete User button.
  • The locked users grid, because a lock may be all that stands between a guessed password and an account that can do more.
  • The two-factor authentication reset button on the user edit page, which needs user management and nothing else and writes no admin user row of its own.

Three things this rule deliberately does not do:

  • A new account has nothing to take over, so it is judged by what it is granted instead, under Rule 2.
  • Negative (deny) roles never put an account out of reach. They only take access away, so holding one cannot make an account more powerful.
  • Your own account is always within reach. What you may change about your own access is Rule 1's business, not this rule's.

Lapsed grants count towards the check, because re-dating one hands the access back.

Rule 4: Nobody Hands Out Access That Outlives Their Own

Time is part of how much access someone has. An admin whose own grants all carry an expiry can only create access that ends no later than theirs:

  • A role they assign to an admin user inherits their last day.
  • A later expiry date on an admin user's grant is refused outright.
  • An integration grant added in the same call is silently capped at their last day instead of refused.
  • Clearing someone else's expiry caps it at their own horizon instead of making it open-ended.
  • Negative (deny) role grants are never capped, because a negative role's grant cannot have an end date.

Hold one open-ended grant, as every ordinary administrator does, and there is no horizon to apply. This rule only bites on admins whose own access is entirely time-boxed. Negative roles don't count toward that horizon: a negative role's grant never has an end date, but it grants nothing, so a time-boxed admin who also holds a negative role is still capped at their own last day.

Taking Access Away from Someone Else

Rules 2 to 4 never refuse taking ACL access away from someone else. An admin with narrow permissions can still strip a colleague whose roles reach further than their own. Locking someone out is rarely the dangerous direction, and an incident response that needed the right permissions first would be no use.

Taking access away is still refused in these cases:

  • Your own access. Rule 1 refuses any change to your own roles or expiries, in either direction.
  • Making a role negative that would lock a holder out. Flagging a role as negative is refused when the role allows all resources, when you hold the role yourself, or when it would leave any holder with no role that grants anything. See Negative (Deny) Roles.
  • Widening someone's scopes by taking a role away. With the scope restriction module enabled, a scope-restricted admin cannot remove a role, delete a role or set an end date on a grant when the user would afterwards reach a website or store view the admin cannot reach. The typical case is taking away the only restricting role from someone who also holds an unrestricted one. The message reads: This would let "%1" reach a website or store view your own account cannot reach.

When the Rules Do Not Apply

All four guardrails stand down when no admin is acting. The CLI, cron, data patches and the installer have no session to escalate from, and gating them would make the module impossible to seed. The security boundary is the acting admin's session, not the code path.

Integrity checks that don't depend on an acting admin still apply on the command line: a role that allows all resources, or whose flagging would lock a holder out, cannot be made negative, and a negative role's grant cannot have an end date.

Command line access is full access

Anyone who can run bin/magento on the server can lift any scope restriction, clear negative flags, create a full administrator with admin:user:create or write to the database directly. The command line tools are not gated by these rules. Treat shell access to the Magento installation as equivalent to full administrator access, because it is.

What a Refused Save Looks Like

A refused write raises an AuthorizationException, which the admin panel reports as an error message on the page you were on. Nothing is half-applied: role reconciliation runs in one transaction, so a refusal leaves the user exactly as they were.

Refused attempts are recorded too, on every path that can refuse one. The Role Assignment Audit Log lists them as Grant failed, Revocation failed or Making a role negative failed, with the roles they would have changed and the reason they did not go through. If you are trying to work out why a colleague could not hand out a role, that grid is the place to look.

Refused a grant you think you should be allowed?

Check the Effective Permissions viewer for your own account first. Rule 2 compares the role being granted against everything you are allowed, so a single resource you're missing is enough to block the whole grant. The viewer shows which resources those are.