feat: let the catalog declare a device, fixing Mysterium's missing TUN (CashPilot-6rv) - #157
Conversation
…N (CashPilot-6rv) A service could declare cap_add but not a device, and the orchestrator had no device support at all. Mysterium needs /dev/net/tun to carry wireguard/dvpn traffic; without it the node starts, registers, advertises itself to the network and carries nothing. Every view CashPilot had of it looked healthy, so it took a provider email to surface - the exact "running is not earning" case. Service YAML now supports `devices:`, and mysterium.yml declares /dev/net/tun. A device is a direct line to the kernel, so this is deliberately not a passthrough: - The worker holds a hard allow-list (_ALLOWED_DEVICES) that the catalog cannot widen. Adding an entry is a maintainer decision in code, not something a service YAML can do on its own. - Requests are scoped per-slug, the same rule already used for cap_add: a service may only ask for what its OWN yaml declares. With a union, one service declaring a device would grant it to the other 49. - An unknown slug gets the empty set - deny, never fall back to the union. - A host-path remap is judged on the HOST path, so /dev/mem:/dev/net/tun is refused rather than smuggled through on its container-side name. Tests cover the refusals rather than just the happy path, including /dev/mem, /dev/kmsg, raw block devices, /dev/kvm, a traversal attempt, and the remap above. One test asserts the catalog can never declare a device outside the ceiling, and another that deploy_raw actually forwards it - a declaration nothing forwards would protect nobody.
|
Warning Review limit reached
Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #157 +/- ##
==========================================
- Coverage 94.23% 94.23% -0.01%
==========================================
Files 36 36
Lines 4475 4492 +17
==========================================
+ Hits 4217 4233 +16
- Misses 258 259 +1
🚀 New features to boost your workflow:
|
Closes the P1 behind the MystNodes failure documented in #155.
The gap
A service could declare
cap_addbut not a device, and the orchestrator had no device support at all. Mysterium needs/dev/net/tunto carry wireguard/dvpn traffic. Without it the node starts, registers, advertises itself to the network — and carries nothing.Every view CashPilot had of it looked healthy. It took a provider email to surface. That is precisely the "running is not earning" case.
The fix
Service YAML now supports
devices:, andmysterium.ymldeclares/dev/net/tun.Deliberately not a passthrough
A device is a direct line to the kernel, so:
_ALLOWED_DEVICES) that the catalog cannot widen. Adding an entry is a maintainer decision in code, not something a service YAML can do on its own.cap_add: a service may only request what its own YAML declares. With a union, one service declaring a device would grant it to the other 49./dev/mem:/dev/net/tunis refused rather than smuggled through on its container-side name.Tests target the refusals
/dev/mem,/dev/kmsg, raw block devices,/dev/mapper/control,/dev/kvm, a traversal attempt, and the remap above — plus two structural guards:deploy_rawactually forwards it — a declaration nothing forwards would protect nobodyVerification
ruff check . && ruff format --check .— cleanpytest --cov=app --cov-fail-under=90— 1470 passed, coverage 94.90%