[question] Unexpected behaviour group match

[sangamk]

Describe the bug
Given a group with numerical values m = g(r.user, p.role, r.tag) and g, 1, 2, proj-1, I get true when I try to match user with id 2 even though that group does not exist.

To Reproduce
Steps to reproduce the behavior:

1. Policy, I removed all the fluff:

[request_definition]
r = user, path, method, tag

[policy_definition]
p = role, path, method, tag

[policy_effect]
e = some(where (p.eft == allow))

[role_definition]
g = _, _, _

[matchers]
m = g(r.user, p.role, r.tag)

2. Example policy:

p, 1, /something, GET, proj-*
g, 2, 1, proj-1
g, 3, 1, proj-1

3. Perform the following request:

1, /something, GET, proj-1

Expected behavior
When I run the code above in the online editor or in the lib I expect the return to be false instead it is true.

If I change my policy:

p, r1, /something, GET, proj-*
g, 2, r1, proj-1
g, 3, r1, proj-1

Then it works as expected.
Desktop (please complete the following information):

• OS: Macbook
• Browser Chrome

Additional context
In the online editor I get the same issue:
https://editor.casbin.org/#3ZLSE3E75

[casbin-bot]

@tangyang9464 @JalinWang

[feellmoose]

There is a note for this question in [RBAC | Casbin](https://casbin.org/docs/rbac/)

3. Do not use the same name for a user and a role inside an RBAC system, because Casbin recognizes users and roles as strings, and there's no way for Casbin to know whether you are specifying user alice or role alice. You can simply solve it by using role_alice.

Given policies

p, 1, /something, GET, proj-*
g, 2, 1, proj-1
g, 3, 1, proj-1

1. Role 1 has a policy that allows GET actions on the /something resource for all projects matching proj-*.
2. Users 2 and 3 inherit the permissions of Role 1 for the project proj-1. Therefore, users 2 and 3 have GET access to /something within the proj-1 project.

The issue arises when User 1, who is not explicitly granted the permissions of Role 1, also acquires those permissions.

Behavior

When adds the inheritance link between two roles (role: name1 and role: name2), we while add map between strings.

In such cases, a role in the policy is also treated as a user. Consider the following model configuration:

[request_definition]
r = user, path, method

[policy_definition]
p = role, path, method

[policy_effect]
e = some(where (p.eft == allow))

[role_definition]
g = _, _

[matchers]
m = g(r.user, p.role)

And the following policy:

p, admin, /something, GET
g, alice, admin
g, bob, admin

When we use admin to access /something with the GET method, it will also be allowed because the admin role is treated as a user.

In this model, roles can effectively act as users, allowing them to inherit permissions directly. This behavior must be carefully managed to ensure that roles and users are assigned appropriately and to avoid unintended permission grants.

[sangamk]

Thanks for explaining. Makes sense