dohertj2/lmxopcua
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases Wiki Activity

ACL: Server-object (i=2253) event subscriptions bypass the data-plane ACL #586

New Issue
Closed
opened 2026-10-07 23:13:41 -04:00 by dohertj2 · 1 comment
dohertj2 commented 2026-10-07 23:13:41 -04:00
Owner
Copy Link
Copy Source

Found while closing #562 (event/alarm monitored-item revalidation).

What is wrong: an event monitored item on the Server object (i=2253) bypasses the data-plane ACL entirely — at creation and at revalidation. The SDK routes it through SubscribeToAllEvents and the core node manager's Server object, which OtOpcUaNodeManager never sees, so neither the SubscribeToEvents creation gate nor the #562 revalidation map applies.

Observed over the wire (throwaway probe, not committed): with Security:Acl:Enabled=true, an anonymous session holding no grant received a native alarm through a Server-object event item.

Why it matters: native alarms report once to the Server object (one ReportEvent, one Server-object copy — see CLAUDE.md), so this is the one feed that carries every alarm in the server, and it is ungated when ACL enforcement is on.

To do:

  • Filter events at the point the Server object delivers them to a monitored item, per the item's session identity, using the same DataPlaneAuthorizer decision as the per-folder path (the event's source / ConditionId → RawPath scope).
  • Revalidated by both triggers (deploy + AclRevalidationTimer), reversibly.
  • Over-the-wire test: no-grant session gets nothing via i=2253; granted session gets the event (positive control); revoke → stops; restore → resumes.
  • Update docs/security.md + CLAUDE.md (the residual added by #562).
Found while closing #562 (event/alarm monitored-item revalidation). **What is wrong:** an event monitored item on the **Server object** (`i=2253`) bypasses the data-plane ACL entirely — at creation and at revalidation. The SDK routes it through `SubscribeToAllEvents` and the core node manager's Server object, which `OtOpcUaNodeManager` never sees, so neither the `SubscribeToEvents` creation gate nor the #562 revalidation map applies. **Observed over the wire** (throwaway probe, not committed): with `Security:Acl:Enabled=true`, an anonymous session holding **no grant** received a native alarm through a Server-object event item. **Why it matters:** native alarms report once to the Server object (one `ReportEvent`, one Server-object copy — see CLAUDE.md), so this is the one feed that carries every alarm in the server, and it is ungated when ACL enforcement is on. **To do:** - [ ] Filter events at the point the Server object delivers them to a monitored item, per the item's session identity, using the same `DataPlaneAuthorizer` decision as the per-folder path (the event's source / ConditionId → RawPath scope). - [ ] Revalidated by both triggers (deploy + `AclRevalidationTimer`), reversibly. - [ ] Over-the-wire test: no-grant session gets nothing via `i=2253`; granted session gets the event (positive control); revoke → stops; restore → resumes. - [ ] Update docs/security.md + CLAUDE.md (the residual added by #562).
dohertj2 commented 2026-10-08 01:53:58 -04:00
Author
Owner
Copy Link
Copy Source

Fixed: i=2253 items are delivered per condition with the same DataPlaneAuthorizer decision as the folder path (condition RawPath, notifier folders, equipment folders), the ungated folder→Server forward removed, ConditionRefresh filtered, SDK audit guard mirrored, EventsMonitored bookkeeping maintained. Independently reviewed (fix round + re-review APPROVE). Model-change/audit residual → #588. (merge 390c8269 on master, pushed 2026-10-08)

Fixed: i=2253 items are delivered per condition with the same DataPlaneAuthorizer decision as the folder path (condition RawPath, notifier folders, equipment folders), the ungated folder→Server forward removed, ConditionRefresh filtered, SDK audit guard mirrored, EventsMonitored bookkeeping maintained. Independently reviewed (fix round + re-review APPROVE). Model-change/audit residual → #588. (merge `390c8269` on master, pushed 2026-10-08)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 cross-driver
queue management
 driver/abcip
queue management
 driver/ablegacy
queue management
 driver/focas
queue management
 driver/mqtt
MQTT / Sparkplug B broker-subscribe driver
 driver/opcuaclient
queue management
 driver/s7
queue management
 driver/twincat
queue management
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#586
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?