Make matchers part of the Policy interface #2514
Conversation
hscontrol/mapper/mapper.go
Outdated
| @@ -529,7 +529,8 @@ func appendPeerChanges( | |||
| // If there are filter rules present, see if there are any nodes that cannot | |||
| // access each-other at all and remove them from the peers. | |||
| if len(filter) > 0 { | |||
| changed = policy.FilterNodesByACL(node, changed, filter) | |||
| matchers := polMan.Matchers() | |||
There was a problem hiding this comment.
It occurred to me after the implementation that this could be subject to race conditions -- the ACLs could be updated between the call polMan.Filter() and the call to polMan.Matchers().
Would it maybe make more sense if Policy.Filter() returned a tuple ([]tailcfg.FilterRule, []matcher.Match) so that the returned filter rules and matches are always in sync?
There was a problem hiding this comment.
That is a good point, I think that is fair, particularly since it will just be returned and not computed. can probably just underscore the matchers when we dont need them.
There was a problem hiding this comment.
Done (and also added matchers to tests where the Policy function is tested).
|
Given that there is already a changelog section on the policy rework, do you think that a separate entry is necessary for this change? |
| @@ -69,6 +71,9 @@ func (pm *PolicyManager) updateLocked() (bool, error) { | |||
| filterChanged := filterHash == pm.filterHash | |||
| pm.filter = filter | |||
| pm.filterHash = filterHash | |||
| if filterChanged { | |||
There was a problem hiding this comment.
There is a couple of failing tests, not sure why, I wonder if this somehow could be the cause if it prevents the matchers from being generated in some conditions, like empty policies? I really do not think it should be related, but I cant see anything else special about v2.
There was a problem hiding this comment.
Isn't the filterChanged actually computed incorrectly a few lines above? Wouldn't filterChanged := filterHash != pm.filterHash make more sense? Should I change that?
There was a problem hiding this comment.
oh dear, you are right... yes please.
Pull Request Revisions
|
![review-ai-agent[bot]](https://avatars.githubusercontent.com/in/1104228?s=60&v=4){kind=small}
| @@ -66,9 +68,12 @@ func (pm *PolicyManager) updateLocked() (bool, error) { | |||
| } | |||
|
|
|||
| filterHash := deephash.Hash(&filter) | |||
| filterChanged := filterHash == pm.filterHash | |||
| filterChanged := filterHash != pm.filterHash | |||
There was a problem hiding this comment.
I see that only SSH tests in v2 fail now, I suspect that it is because there was a bug here that never returned "early" on line 102, causing 110 (clear ssh) to always run. Now that it does return early, I suspect that my logic for when the ssh needs to be clear is wrong, and it wasnt discovered because of this.
There was a problem hiding this comment.
I don't know if this occurs in the integration tests, but here is an example where I think updateLocked behaves incorrectly with the early return: If only the SSHs field of the policy changes, the call to updateLocked in SetPolicy would AFAICT return false, nil, but the SSH policy needs to be recompiled nevertheless in this case.
Would it maybe make sense to just always clear the SSH policy map or add an additional guard checking whether the SSHs field of the policy has changed?
This PR makes the
Matches that are computed fromFilterRules part of thePolicyinterface, so that they don't have to be recomputed at each call toNode.CanAccess. There have already been some discussion on this approach in #2416.