fix(server): match access rule patterns against the whole value - #7018
Merged
Conversation
The public-key device filter, the public-key username restriction and the Access Policy device filter all selected with regexp.MatchString(pattern, value), which succeeds on any substring. An administrator who writes "staging" into a device filter is naming the staging host; what the server enforced was every device whose name contains "staging", including notstaging, staging-db and prod-staging-mirror. A key restricted to "root" also authorized the login "notroot". The fields are regexps and are documented as regexps, so this was the semantics they carried rather than a break in them. It is still the wrong default for a field that decides access: the operator types a hostname and gets a substring rule, and the surprise runs in the permissive direction. Within one rule the mismatch shows. subjectMatches and loginMatches compare with ==, sourceIPMatches uses netip.Prefix.Contains, so logins:["ubuntu"] refused "ubuntu2" while filter.hostname:"staging" accepted "notstaging" - two selectors on the same policy reading their values by different rules. MatchPattern wraps the pattern as \A(?:pattern)\z. The non-capturing group is load-bearing: anchoring "a|b" without it yields \Aa|b\z, which means something else entirely. \A and \z rather than ^ and $ so that a (?m) pattern cannot pass off one line of a multiline value as a whole match. This narrows every stored pattern that relied on substring matching. A filter written as "staging" now selects only the device named "staging"; an operator who depended on the wider reach needs "staging.*" or a tag filter. That is a breaking change for such deployments and wants a release note. Reported-by: Eduardo Barbosa <Edu0x01@users.noreply.github.com>
Code Review CompleteThe automated review ran but did not post an updated summary — this usually means no new issues were found since the previous review. If you've pushed changes and want a fresh pass, comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The public-key device filter, the public-key username restriction and the Access Policy device
filter all selected with
regexp.MatchString(pattern, value), which succeeds on any substring. Afilter written as
stagingreachednotstaging,staging-dbandprod-staging-mirror; a keyrestricted to
rootalso authorized the loginnotroot.These fields are regexps and are documented as regexps, so this was the semantics they carried
rather than a break in them. It is still the wrong default for a field that decides access: the
operator types a hostname and gets a substring rule, and the surprise runs in the permissive
direction. Within a single policy the inconsistency is visible —
logins: ["ubuntu"]refusedubuntu2whilefilter.hostname: "staging"acceptednotstaging.What changes
models.MatchPatternwraps the pattern as\A(?:pattern)\zand every matcher goes through it:PublicKeyFilter.Matches— the device selector shared by the public-key ACL and Access PoliciesEvaluateKeyUsername— the public-key username restrictionThe non-capturing group is load-bearing: anchoring
a|bwithout it yields\Aa|b\z, which meanssomething else.
\A/\zrather than^/$so a(?m)pattern cannot pass one line of amultiline value off as a whole match.
An empty pattern still matches anything, and
.*— the value the console stores for "all devices"— still matches every name.
Breaking change
This narrows every stored pattern that relied on substring reach. A filter written as
stagingnowselects only the device named
staging; an operator who depended on the wider reach needsstaging.*or a tag filter. It wants a release note.Notes
Cloud carries the same matcher in its firewall rule evaluator; shellhub-io/cloud#2530 moves those
three call sites onto
MatchPatternand is blocked on this landing.Documentation and console copy are updated separately, in the companion PR, so the wording change
can be read on its own.
Reported by Eduardo Barbosa (@Edu0x01).