chore: run coder connect networking from launchdaemon #203
+532
−493
Conversation
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
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
ethanndickson
force-pushed
the
ethan/networking-in-launchdaemon
branch
from
49d5c99 to
72071e5
Compare
ethanndickson
changed the base branch from
graphite-base/203
to
ethan/mandatory-helper
This was referenced Jul 24, 2025
ethanndickson
force-pushed
the
ethan/networking-in-launchdaemon
branch
from
72071e5 to
c7dbde8
Compare
ethanndickson
force-pushed
the
ethan/networking-in-launchdaemon
branch
from
c7dbde8 to
ef8832a
Compare
ethanndickson
force-pushed
the
ethan/mandatory-helper
branch
from
1737580 to
16c716d
Compare
ethanndickson
force-pushed
the
ethan/networking-in-launchdaemon
branch
from
ef8832a to
e32d7de
Compare
ethanndickson
commented
Jul 30, 2025
Comment on lines
66
to
77
| guard let proxy = conn.remoteObjectProxyWithErrorHandler({ err in | ||
| self.logger.error("failed to connect to HelperXPC \(err.localizedDescription, privacy: .public)") | ||
| continuation.resume(throwing: err) | ||
| }) as? HelperAppXPCInterface else { | ||
| self.logger.error("failed to get proxy for HelperXPC") | ||
| continuation.resume(throwing: XPCError.wrongProxyType) | ||
| return | ||
| } | ||
| proxy.ping { | ||
| self.logger.info("Connected to Helper over XPC") | ||
| continuation.resume() | ||
| } |
There was a problem hiding this comment.
Important to note that I've refactored all the XPC connections to use this pattern. With this, you're guaranteed that either the the XPC reply will be run (proxy.ping { reply } in this case) or the [...]WithErrorHandler callback.
ethanndickson
commented
Jul 30, 2025
Comment on lines
+14
to
+15
| // /var/root/Downloads | ||
| private let dest = FileManager.default.urls(for: .downloadsDirectory, in: .userDomainMask) |
There was a problem hiding this comment.
Temporary. I've put it in /var/root/Library/Application\ Support/com.coder.Coder-Desktop/ as part of the PR that downloads the slim binary.
ethanndickson
force-pushed
the
ethan/networking-in-launchdaemon
branch
from
eebf562 to
291e5a1
Compare
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.
Continues to address #201.
This PR reworks all XPC connections, such that the networking code runs within the privileged helper, instead of the network extension.
The XPC interfaces are described in
XPC.swift, and roughly follow this sequence diagram:(One difference is that we don't posix spawn the tunnel in this PR)
sequenceDiagram note left of App: User requests to start VPN: App->>+NetExt: Start VPN NetExt->>+PrivHelper: Request start VPN with TUN FD note right of PrivHelper: Privileged helper downloads and verifies binary. PrivHelper->>Tunnel: posix_spawn child process with FDs PrivHelper->>+Tunnel: Send proto start request Tunnel-->>-PrivHelper: Send proto start response PrivHelper->>+NetExt: Request for network config change NetExt-->>-PrivHelper: Response for network config change PrivHelper-->>-NetExt: Start VPN respons NetExt-->>-App: VPN started App->>PrivHelper: Request peer state PrivHelper->>Tunnel: Request peer state Tunnel-->>PrivHelper: Peer state response PrivHelper-->>App: Peer state response note left of App: Tunnel updates (bypass NetExt): Tunnel->>PrivHelper: Tunnel update proto message PrivHelper->>App: Tunnel update proto message note left of App: User requests to stop VPN: App->>+NetExt: Stop VPN NetExt->>+PrivHelper: Request stop VPN PrivHelper->>+Tunnel: Request stop VPN Tunnel-->>-PrivHelper: Stop VPN response note right of Tunnel: Tunnel binary exits PrivHelper-->>-NetExt: Stop VPN response NetExt-->>-App: VPN stoppedOf note is that the network extension starts and stops the daemon running within the privileged helper.
This is to support starting and stopping the VPN from the toggle in System Settings, and to ensure the "Connecting" and "Disconnecting" phase of the system VPN is indicative of the time the VPN is actually setting itself up and tearing itself down.
To accomplish this, the privileged helper listens on two different service names. One is connected to by the app, the other the network extension. (Once an XPC listener is connected to, communication is bidirectional)