add_named_matching_func not fully functional in 1.2.0

[natbusa]

Hi, there is some change applied in 1.2.0 which is preventing the following code and rules to run as they were in 1.1.3
The policy was working fine in 1.1.3. I believe it has something to do with "g2", add_named_matching_func and fm functions

code:

enforcer = casbin.Enforcer("./rbac.conf", "./policy.csv")
enforcer.add_named_matching_func("g2", enforcer.fm.fm["globMatch"])

rbac.conf:

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, role

[role_definition]
g  = _, _
g2 = _, _

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

[matchers]
m = g2(r.act, p.role) && (g(r.sub, p.sub) || p.sub=='*') && keyMatch(r.obj, p.obj)

policy.csv

p, root, *, owner
g, root@localhost, root
g2, *.*, owner

expected:
root@localhost, /, org.create -> PASS (get a FAIL in 1.2.0)

[leeqvip]

@Zxilly

[Zxilly]

working on this

[natbusa]

many thanks 🙏

[Zxilly]

@natbusa Hello, could you please provide more infomation about your environment? I created a unit test https://github.com/Zxilly/pycasbin/commit/dc9bbff092967344f0b04a9537e53f658e8cd464 to test the situation, but I failed to reproduce.

[natbusa]

Hi @Zxilly many thanks for looking at this. I confirm your findings, and I was able to isolate the problem further.
It happens when there are multiple g2 rules (which I had removed for simplicity, but indeed did not trigger the error)

############################
## policies
############################

# app root super-users
p, root, *, owner
g, root@localhost, root

############################
## roles to scope.verb
############################

g2, *.read, viewer

g2, *.read, editor
g2, *.update, editor

g2, *.read, admin
g2, *.update, admin
g2, *.create, admin
g2, *.delete, admin

g2, *.*, owner

I have re-run the test in a clean conda python 3.8 environment with only casbin pip installed (1.1.3 vs 1.2.0)
What happens is that somehow the g2 rule g2, *.create, admin and the g2, *.*, owner impact the final outcome in 1.2.0

[ffyuanda]

@natbusa Hi natbusa, just curious (might not directly relate to the issue), I see your policy definition [policy_definition] p = sub, obj, role.
I believe in the convention of casbin the role here should be act?
And in the matcher you wrote g2(r.act, p.role), are you intending to classify an act under a role?

[natbusa]

Hi @ffyuanda , happy to provide more context. I have designed an rbac which was putting together users, groups and resources and also with a mechanism capable of matching roles to api actions defined as scope.verb as in org.create or article.update

So as you see above the request has an action for example 'org.create' while the user has a role for example 'admin' (indirectly via a group 'root'.)

So g2(r.act, p.role) matches the request api scope e.g. org.create to any user registered the roles admin and owner, while i keep g(r.sub, p.sub) to match users belonging to a given group (for example root@localhost the group root). It's a pattern which I find works quite well for scoped API and multiple user groups.

I haven't had the time so far to properly write down a more thorough example here at (py)casbin ...

[Zxilly]

I have located the problem. It was because role manager will use the first gRule hit by matching_func to judge the link between the roles. In this example, it's *.create and org.create, it hit rule g2, *.update, admin, admin is not owner and g2() return false immediately.
I will later fix this.

[Zxilly]

@natbusa Can I add your configuration files to our unittests as a edge-case?

[natbusa]

@Zxilly you can add to the unittests . Many thanks for locating the problem!