migration: phase 2 — adapters can target local syva-core by yairfalse · Pull Request #49 · false-systems/syva

yairfalse · 2026-04-26T23:35:10Z

Summary

Adds syva-core-client, a thin shared Unix-socket tonic client for the node-local syva.core.v1 API, so adapters do not duplicate connector code.
Adds local-core mode to syva-file, syva-k8s, and syva-api behind --core-socket, while keeping existing --cp-endpoint CP mode intact.
Adds local-core translation paths alongside the existing CP translations and documents the CP-only fields that are dropped in local mode.
Adds file-adapter desired/applied diffing for local core and focused tests for local-core translation/body mapping.

Design Notes

I used a new syva-core-client crate rather than putting the connector in syva-proto because syva-proto is currently just generated API types. Keeping transport/retry code in a sibling client crate mirrors syva-cp-client and avoids making the proto crate responsible for runtime client behavior.

syva.core.v1.ZonePolicy has typed fields only: host_paths, allowed_zones, allow_ptrace, and zone_type. Local-mode translations intentionally drop CP-only display_name, selector_json, and metadata. The API adapter also rejects unknown local policy_json fields so operators see the narrower local schema instead of assuming CP semantics still apply.

Verification

Succeeded on this macOS host:

$ cargo check -p syva-core-client -p syva-adapter-api -p syva-adapter-k8s
Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.26s

$ cargo check -p syva-adapter-file --target x86_64-unknown-linux-gnu
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.44s

$ cargo check -p syva-adapter-file --tests --target x86_64-unknown-linux-gnu
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s

$ cargo test -p syva-adapter-api -p syva-adapter-k8s
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

$ git diff --check
<no output>

Attempted but blocked by host/toolchain, not by this patch:

$ cargo build --workspace
error[E0432]: unresolved imports `libc::nlattr`, `libc::nlmsgerr`, `libc::nlmsghdr`, `libc::sockaddr_nl`, `libc::AF_NETLINK`, ...
error[E0432]: unresolved imports `libc::SYS_bpf`, `libc::SYS_perf_event_open`
error[E0425]: cannot find value `CLOCK_BOOTTIME` in crate `libc`
error: could not compile `aya` (lib) due to 3 previous errors

$ cargo test --workspace
same `aya` Linux-only libc/netlink symbol failure on macOS

$ cargo check --workspace --target x86_64-unknown-linux-gnu
error occurred in cc-rs: failed to find tool "x86_64-linux-gnu-gcc": No such file or directory

Manual smoke test was not run because this machine is macOS and does not have Linux kernel BPF support.

Surprises

The Phase 1 core server currently rejects proto ZONE_TYPE_ISOLATED = 2; parse_proto_zone_type accepts only standard 0 and privileged 1. Local adapter translations therefore map isolated to standard for now. This should be revisited when local core accepts the full proto enum.

Copilot

Pull request overview

Adds a shared Unix-socket gRPC client for the node-local syva.core.v1 API and updates multiple adapters (file/k8s/api) to optionally target a local syva-core via --core-socket while keeping existing CP (--cp-endpoint) mode.

Changes:

Introduces new syva-core-client crate to centralize tonic Unix-socket connection + retry logic for syva.core.v1.
Adds dual-mode (CP vs local-core) configuration and execution paths to syva-file, syva-k8s, and syva-api.
Implements local-core translation/mapping and adds focused tests + a name-based desired/applied diff helper for file adapter core mode.

Reviewed changes

Copilot reviewed 16 out of 17 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
syva-core-client/src/lib.rs	New Unix-socket tonic client and retry loop for local `syva-core`.
syva-core-client/Cargo.toml	New crate manifest with tonic/tokio/tower/hyper-util deps.
syva-adapter-k8s/src/watcher.rs	Adds CP vs local-core mode selection and local-core reconcile/apply/delete paths.
syva-adapter-k8s/src/mapper.rs	Adds CRD → `syva.core.v1.RegisterZoneRequest` translation + tests.
syva-adapter-k8s/src/main.rs	Adds `--core-socket` and makes CP args optional/validated.
syva-adapter-k8s/Cargo.toml	Adds dependency on `syva-core-client`.
syva-adapter-file/src/translate.rs	Adds file policy → local-core `RegisterZoneRequest` mapping + tests.
syva-adapter-file/src/run.rs	Adds CP vs local-core run modes; local-core reconcile loop and core RPC usage.
syva-adapter-file/src/main.rs	Adds `--core-socket` and makes CP args optional/validated.
syva-adapter-file/src/lib.rs	Exposes new `diff` module.
syva-adapter-file/src/diff.rs	Adds desired-vs-applied name diffing for local-core reconcile + tests.
syva-adapter-file/Cargo.toml	Adds dependency on `syva-core-client`.
syva-adapter-api/src/routes.rs	Adds CP vs local-core state/mode; routes can operate against core via Unix socket.
syva-adapter-api/src/main.rs	Adds `--core-socket` and makes CP args optional/validated.
syva-adapter-api/Cargo.toml	Adds dependency on `syva-core-client`.
Cargo.toml	Adds `syva-core-client` to workspace members.
Cargo.lock	Locks new crate and its dependency edges into the workspace.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-26T23:42:31Z

+    let create = desired_names
+        .difference(&applied_names)
+        .map(|name| (*name).to_string())
+        .collect();
+    let update = desired_names
+        .intersection(&applied_names)
+        .map(|name| (*name).to_string())
+        .collect();


diff_against_core marks every zone present in both desired and applied as update, regardless of whether the policy actually changed. As a result, reconcile_once_core will re-register every existing zone on every tick, and re-run host-path + comm registration loops, which can cause unnecessary BPF map churn. If core doesn’t expose applied policy details, consider diffing against an in-memory last-applied snapshot (policy hash/JSON) and only updating when the desired policy changes, while still doing a full refresh on startup.

Copilot · 2026-04-26T23:42:31Z

+        core.register_zone(spec_to_core_register(&name, crd))
+            .await?;
+        info!(zone = %name, "zone registered from CRD (initial)");


Local-core mode registers zones via register_zone, but syva-core currently does not translate ZonePolicy.allowed_zones into ZONE_ALLOWED_COMMS entries (those are only set via the allow_comm RPC). That means CRD allowed_zones will have no effect in local-core mode. To match CP semantics, reconcile comm pairs explicitly (and deny pairs that are no longer mutually allowed).

Copilot · 2026-04-26T23:42:32Z

+    Ok(RegisterZoneRequest {
+        zone_name: name.to_string(),
+        policy: Some(ZonePolicy {
+            host_paths: policy.host_paths,
+            allowed_zones: policy.allowed_zones,
+            allow_ptrace: policy.allow_ptrace,
+            zone_type: match policy.zone_type {
+                CoreZoneType::Privileged => 1,
+                CoreZoneType::Standard | CoreZoneType::Isolated => 0,
+            },
+        }),


In local-core mode core_register_request accepts/forwards allowed_zones, but the handlers only call register_zone. In the current syva-core implementation, cross-zone comms are enforced via ZONE_ALLOWED_COMMS and are only updated through the allow_comm / deny_comm RPCs, not via register_zone. As a result, allowed_zones from the API won’t actually be applied in local-core mode. Consider either (a) translating allowed_zones into comm-pair reconciliation in the adapter, or (b) removing/ignoring allowed_zones from the accepted local-core schema until core enforces it via register_zone.

Copilot · 2026-04-26T23:42:32Z

+            if let Some(status) = query.status {
+                zones.retain(|zone| zone.state == status);
+            }
+            zones.truncate(query.limit.unwrap_or(100).max(0) as usize);


zones.truncate(query.limit.unwrap_or(100).max(0) as usize) can wrap on 32-bit targets if a client passes a large limit (because the as usize cast truncates). Prefer clamping with usize::try_from(limit).unwrap_or(usize::MAX) (after handling negatives) to avoid surprising behavior.

Suggested change

zones.truncate(query.limit.unwrap_or(100).max(0) as usize);

let limit = query.limit.unwrap_or(100).max(0);

let limit = usize::try_from(limit).unwrap_or(usize::MAX);

zones.truncate(limit);

Copilot · 2026-04-26T23:42:32Z

+    for path in &policy.policy.filesystem.host_paths {
+        core.register_host_path(RegisterHostPathRequest {
+            zone_name: name.to_string(),
+            path: path.clone(),
+            recursive: true,
+        })
+        .await?;
+    }


register_host_path only ever adds/populates inode entries; there is no corresponding removal here. If a host path is removed from the desired policy, the old inode mappings will remain in INODE_ZONE_MAP until the whole zone is removed/drained, meaning local-core updates can only widen filesystem access over time. If policy updates are expected to be authoritative, consider adding/using a core RPC to clear a zone’s inode mappings (or re-register by clearing inodes first) so removals take effect.

Copilot · 2026-04-26T23:42:32Z

+    for allowed_zone in &policy.policy.network.allowed_zones {
+        if let Err(error) = core
+            .allow_comm(AllowCommRequest {
+                zone_a: name.to_string(),
+                zone_b: allowed_zone.clone(),
+            })
+            .await
+        {
+            warn!(zone = %name, peer = %allowed_zone, error = %error, "allow_comm failed");
+        }
+    }


In local-core mode this uses allow_comm for every allowed_zone listed in a single zone’s policy. In syva-core, allow_comm writes both directions (A→B and B→A) into ZONE_ALLOWED_COMMS (see syva-core/src/ebpf.rs), which means a one-sided allowed_zones entry grants bidirectional comms and weakens the intended “mutual allow” semantics used by CP reconcile. Also, this never issues deny_comm, so removing an entry from allowed_zones will not revoke previously-allowed comms. Consider reconciling comm pairs by: (1) deriving desired mutual pairs from all on-disk policies, (2) listing current pairs from core (ListComms), then (3) calling allow_comm/deny_comm to converge.

Suggested change

for allowed_zone in &policy.policy.network.allowed_zones {

if let Err(error) = core

.allow_comm(AllowCommRequest {

zone_a: name.to_string(),

zone_b: allowed_zone.clone(),

})

.await

{

warn!(zone = %name, peer = %allowed_zone, error = %error, "allow_comm failed");

}

}

// Do not call `allow_comm` from a single zone's `allowed_zones` entries.

// In local-core mode `allow_comm` programs both directions, so applying it

// here would turn a one-sided declaration into bidirectional communication.

// Communication rules must instead be reconciled globally from the complete

// policy set by deriving mutual pairs and converging core state with

// allow/deny operations.

yairfalse · 2026-04-27T23:51:32Z

Addressed the review comments in ba1609b:

File adapter no longer treats every existing zone as an update on every tick. It keeps a last-applied desired-policy snapshot and only updates existing local-core zones when the desired policy changes, while still refreshing all existing zones once on adapter startup.
File adapter no longer calls allow_comm from one-sided allowed_zones entries. It now derives desired communication policy globally from the complete policy set, requires mutual declarations, compares against ListComms, and converges with allow_comm / deny_comm.
K8s adapter now does the same global mutual-pair comm reconciliation after initial reconcile and after apply/delete watch events.
API local-core mode no longer accepts allowed_zones, because a single REST request has no global policy view and cannot safely enforce mutual-pair semantics. It now rejects that field instead of silently accepting ineffective policy.
Local API limit handling now uses usize::try_from after negative clamping.
File adapter local updates now remove the existing inactive zone with drain=false before re-registering, so inode/path removals can take effect when there are no active containers. If containers are active, the update fails clearly instead of silently widening access.

Verification after the fixes:

cargo check -p syva-core-client -p syva-adapter-api -p syva-adapter-k8s
ok

cargo check -p syva-adapter-file --tests --target x86_64-unknown-linux-gnu
ok

cargo test -p syva-adapter-api -p syva-adapter-k8s
ok: 5 API tests, 8 k8s tests

git diff --check
ok

migration: phase 2 adapters local core mode

e2c9bf9

yairfalse requested a review from Copilot April 26, 2026 23:37

yairfalse self-assigned this Apr 26, 2026

Copilot started reviewing on behalf of yairfalse April 26, 2026 23:37 View session

Copilot AI reviewed Apr 26, 2026

View reviewed changes

fix phase 2 local mode review issues

ba1609b

yairfalse merged commit 9748f95 into main Apr 27, 2026
6 checks passed

yairfalse deleted the migration/phase-2-adapters-local-mode branch April 27, 2026 23:55

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

migration: phase 2 — adapters can target local syva-core#49

migration: phase 2 — adapters can target local syva-core#49
yairfalse merged 2 commits into
mainfrom
migration/phase-2-adapters-local-mode

yairfalse commented Apr 26, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

Copilot AI Apr 26, 2026

Uh oh!

yairfalse commented Apr 27, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-            zones.truncate(query.limit.unwrap_or(100).max(0) as usize);
+            let limit = query.limit.unwrap_or(100).max(0);
+            let limit = usize::try_from(limit).unwrap_or(usize::MAX);
+            zones.truncate(limit);

Conversation

yairfalse commented Apr 26, 2026

Summary

Design Notes

Verification

Surprises

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 26, 2026

Choose a reason for hiding this comment

Uh oh!

yairfalse commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yairfalse commented Apr 27, 2026 •

edited

Loading