Agent role permissions are ignored when there is only a single group

[MacroPolo]

Infos:

• Used Zammad version: 3.6.0-1614608376.e938924d.bionic
• Installation method (source, package, ..): Debian
• Operating system: Ubuntu 18.04
• Database + version: MySQL 5.7
• Elasticsearch version: ES 7.11.1
• Browser + version: Firefox ESR (78.7.0)

Expected behavior:

• Zammad should allow read-only access to agent tickets when only a single group is available.

Actual behavior:

• When only a single group exists (or is enabled), role-based group access for Agent tickets are ignored and full access is granted.

Steps to reproduce the behavior:

1. Create a new role (e.g. "Reader") with "ticket > agent" enabled and "READ" and "OVERVIEW" checked for the "Users" group.
2. Assign the new role to a new user (e.g. "Zammad Reader").
3. Assign the new role to the "Open" overview to allow the users to see ticket lists.
4. Login as the new user
5. Navigate to the "Overviews" section and select a ticket
6. Observe how the ticket can be freely edited (full access)
7. As an admin, create a second group (e.g. "Test Group")
8. Check the Permissions for the "Zammad Reader" user and observe how there is now an explicit "FULL" permission ticked for the "Users" group in addition to the "Reader" role.
9. Uncheck the "FULL" permission
10. Now the Zammad Reader correctly only has read-only access to tickets.

In summary: When there is only one group, Zammad behaves as if there is a hidden "FULL" group permission on user accounts which have the Agent permission enabled. This overwrites the explicit role based group permission. Only after creating a second group to "reveal" the implicit access control, can you correct the situation.

Yes I'm sure this is a bug and no feature request or a general question.

[MrGeneration]

Sorry, but this seems to be a technical question.
Please note that this repository is the wrong place for technical questions.
Instead, please refer the Zammad community over at: https://community.zammad.org .

In case this turns out the be a bug and no technical question, we'll transfer the relevant information to this repo!

If you require commercial grade support and are no hosted or support contract customer, you can check out our support contracts here: https://zammad.com/pricing#selfhosted
If you're paying customer already, please consult your Zammad support for assistance! :-)

[MacroPolo]

I am a bit confused about how the above can be construed as a question as I feel I have described a defect in the permissions model. I have also now raised it over on the Community Forum for a second opinion.

Thanks.

[MrGeneration]

It's rather a feature request than a technical question, still, it should life on the community board first.
If you have one group only, it usually™ is not required to restrict this one group even more. (This is the technical question part)

[MacroPolo]

I'm sorry but I respectfully disagree.

Although we only need one logical Group for tickets, we require different levels of permissions for agents accessing that group. Some agents require read/write so that they can respond to customers, others just need read access so that they can view case updates. That second class of users should not be able to modify tickets in any way.

It would appear that Zammad does not support that based on my report above, but the situation is made worse by the fact that the UI suggests that it is (you can assign role based permissions to a single group). This gives a false sense of security and introduces a silent elevation of privilege for agents that would appear to only have read only access according to the configuration in the UI.

[danieleades]

It's rather a feature request than a technical question, still, it should life on the community board first.
If you have one group only, it _usually_™ is not required to restrict this one group even more. (This is the technical question part)

@MrGeneration I don't understand why this means it's not a bug?

you've got silent privilege escalation here. The fact that you don't see "usually™" see it because you expect users to use groups in a certain way really doesn't change that, especially if this isn't documented anywhere.

It's frankly a little concerning to see security issues dismissed out of hand. For clients using Zammad in security-critical contexts this is a massive red flag.

[MrGeneration]

I agree that the documentation may not point this out directly, however, if you have one group only, you'll by default have access as any agent user to that group.

I would agree that it's a bug to provide a permission setting for the single group in question.
I would also agree that this need to be fiddled on documentation terms, however, the rest is not a bug, but functionality (as of now).

I'm sorry.

[MacroPolo]

@MrGeneration Thank you for your patience whilst we discuss this issue. I appreciate it.

I don't think I'm going to be able to make much further progress here but I want to take one more go to try and explain why this is an issue. I feel like the point of my argument is being lost.

... if you have one group only, you'll by default have access as any agent user to that group.

That doesn't make sense, when you have implemented a role based access control system where multiple different categories of "Agents" can be defined with different access levels. Zammad easily lets me create an agent role that has full access to tickets, write-access, read-only access etc.

Why should my "read-only" agents be forced to have full access when there is only one Zammad group and read-only access when there is two Zammad groups? That seems completely arbitrary.

Stated differently, for organisations that only need one Group (let's say a Support group), Zammad won't allow them to use role-based access control for their agents. ALL agents in the organisation, regardless of their role permissions will be granted FULL access to all tickets.

Conversely, an organisation with two Groups (lets say a Support group and Sales group), Zammad will allow them to use role based access control for their agents.

The number of groups (logical containers of tickets) that a customer has, should have no impact on the ability to enforce access control. I can't think of any way that behavior could be deemed "by design" rather than a bug.

[MrGeneration]

So we've been digging deeper and were talking about this topic.
I have to partly revert my revert above statements.

It's correct we by default expects full permissions for single groups.
However, it's not correct that Zammad enforces it (technically) or does not allow different permissions.

---

The issue actually lays hidden in the UI.
Zammad hides group listings if it's only one - in this case also in the backend within user dialogues.
This is the root cause for you not being able to adjust granular permissions.

Your user has a hidden full permission set for your one group.

Manually unhidden group listing

Default view for users