Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Leaf node interest propagation filtering with queue groups - Exact subject not matching #6281

Closed
roeschter opened this issue Dec 19, 2024 · 0 comments · Fixed by #6291
Closed

Leaf node interest propagation filtering with queue groups - Exact subject not matching #6281

roeschter opened this issue Dec 19, 2024 · 0 comments · Fixed by #6291
Assignees
@kozlovic
Labels
defect Suspected defect such as a bug or regression

Comments

@roeschter
Copy link

roeschter commented Dec 19, 2024 •
edited
Loading

Observed behavior

  • A leaf node is connected to a hub through a user with restrictive permissions.
  • In this example case publish allow "services.device.remote-lock"
  • A services is listening on the leaf "services.device.remote-lock" with queue group
  • A client is trying access the service from the hub publishing to "services.device.remote-lock"
  • The message is not received by the leaf

Null tests and context:

  • Setup works when the user permissions have a wildcard in the last element - e.g "services.device.*" - "services.device.>"
  • Setup works when the service connects to the hub with the same user as the leaf node (the leaf node interest propagation is the crux, not the security checks themselves)
  • Setup works when no queue group is used
  • Tracing interest propagation shows that the subject interest is not propagated to the hub

Expected behavior

Subscription interest propagates even if subject allow filter matches the subject exactly.

Suspected reason: This could be a regression in 2.10.23 due to recent fixes to leaf node interest propagation with queue groups

Server and client version

2.10.23
Nats CLI - main branch

Host environment

Windows

Steps to reproduce

Defect case

  1. Start leaf and hub with the configuration files included here
  2. nats --server=nats://127.0.0.1:4223 reply services.device.remote-lock OK
  3. nats request --server=nats://127.0.0.1:4222 services.device.remote-lock Hello

Nulltest-1
2. nats --server=nats://127.0.0.1:4223 sub services.device.remote-lock
3. nats --server=nats://127.0.0.1:4222 pub services.device.remote-lock Hello

Nulltest-2
2. nats --server=nats://127.0.0.1:4222 --user=user2 --password=user2 reply services.device.remote-lock OK
3. nats --server=nats://127.0.0.1:4222 request services.device.remote-lock Hello

20241219_Leafnode_interest_graph_issue.zip
@roeschter roeschter added the defect Suspected defect such as a bug or regression label Dec 19, 2024
@kozlovic kozlovic self-assigned this Dec 19, 2024
kozlovic added a commit that referenced this issue Dec 20, 2024
@kozlovic
[FIXED] LeafNode: queue interest on leaf not propagated with permissi…
69f9847 
…ons on hub

If the hub has a user with subscribe permissions on a literal subject
that the leaf is trying to create a queue subscription on, the interest
may not be propagated.

The issue was caused by the fact that we were checking the permissions
on the key (that includes subject and queue name) instead of the subject
itself.

Resolves #6281

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
@kozlovic kozlovic mentioned this issue Dec 20, 2024
Merged
derekcollison added a commit that referenced this issue Dec 20, 2024
@derekcollison
[FIXED] LeafNode: queue interest on leaf not propagated with permissi…
87e32fe 
…ons on hub (#6291)

If the hub has a user with subscribe permissions on a literal subject
that the leaf is trying to create a queue subscription on, the interest
may not be propagated.

The issue was caused by the fact that we were checking the permissions
on the key (that includes subject and queue name) instead of the subject
itself.

Resolves #6281

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
wallyqs pushed a commit that referenced this issue Jan 8, 2025
@kozlovic @wallyqs
[FIXED] LeafNode: queue interest on leaf not propagated with permissi…
b7c9609 
…ons on hub

If the hub has a user with subscribe permissions on a literal subject
that the leaf is trying to create a queue subscription on, the interest
may not be propagated.

The issue was caused by the fact that we were checking the permissions
on the key (that includes subject and queue name) instead of the subject
itself.

Resolves #6281

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
wallyqs pushed a commit that referenced this issue Jan 8, 2025
@kozlovic @wallyqs
[FIXED] LeafNode: queue interest on leaf not propagated with permissi…
b7b8cf0 
…ons on hub

If the hub has a user with subscribe permissions on a literal subject
that the leaf is trying to create a queue subscription on, the interest
may not be propagated.

The issue was caused by the fact that we were checking the permissions
on the key (that includes subject and queue name) instead of the subject
itself.

Resolves #6281

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@kozlovic kozlovic

Labels
defect Suspected defect such as a bug or regression
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[FIXED] LeafNode: queue interest on leaf not propagated with permissions on hub nats-io/nats-server
2 participants
@roeschter @kozlovic