Support running native process outside sandbox#724
Support running native process outside sandbox#724JaewonHur wants to merge 2 commits intoapple:mainfrom
Conversation
LinuxProcess with `native` property runs outside containerized environment.
| for process in state.vendedProcesses.values where process.native { | ||
| try await process.kill(signal) | ||
| } |
There was a problem hiding this comment.
Why can't they call kill on the LinuxProcess they get back from exec?
There was a problem hiding this comment.
Based on the SandboxService.stop source code, I assumed it's the responsibility of LinuxContainer to clean up processes in VM. SandboxService.stop doesn't kill each process, but just kill container. Then, LinuxContainer kills the init process only, and it's up to the init process whether or not to kill other processes as well (as all others are parented to init process).
But, it's different for native process as it is not under container init process, but directly the child of vminitd. So, I guess for LinuxContainer.kill to be self-confined, it should kill native process as well.
My guess was:
- Container's init process is responsible for other processes in container (that's why
LinuxContainer.killonly kills that init process). vminitdis responsible for that init process, and alsonative processes(that's why I thinkLinuxContainer.killshould killnative processesas well.
There was a problem hiding this comment.
The thing is, you can send ANY signal in kill. The signal doesn't always lead to the container dying. You can send sigwinch if you wanted, which delivering that signal to any native processes might be wrong.
| public struct CreateProcessOptions: Sendable, Codable { | ||
| /// The process is created outside containerized env. | ||
| public var native: Bool | ||
|
|
||
| enum CodingKeys: String, CodingKey { | ||
| case native | ||
| } | ||
|
|
||
| public init(native: Bool) { | ||
| self.native = native | ||
| } | ||
|
|
||
| public init(from decoder: Decoder) throws { | ||
| let container = try decoder.container(keyedBy: CodingKeys.self) | ||
|
|
||
| native = try container.decodeIfPresent(Bool.self, forKey: .native) ?? false | ||
| } | ||
| } |
There was a problem hiding this comment.
The createProcess API takes in an optional containerID. This is what I was going to use to signify that we'd want to run a process in the root of the VM. e.g. supplying a nil containerID.
There was a problem hiding this comment.
I'd prefer we don't introduce new public API like this without really thinking through it
There was a problem hiding this comment.
Oh I forgot. Yeah let me update.
Do you think NativeProcess should live outside of ManagedContainer?
This will need reimplementing bookkeeping structure and management logic for NativeProcess.
There was a problem hiding this comment.
Do you think NativeProcess should live outside of ManagedContainer?
Whatever you think is right. If it feels too much hassle let me know
NativeProcess is a ContainerProcess that runs outside the containerized environment. It's equally managed like the other ManagedProcess, but only runs outside sandbox.
2 participants
This PR supports
NativeProcess, which runs outside of containerized environment.NativeProcessis managed the same asManagedProcess, except it is spawned directly byvminitd(notvexec). These processes run outside of container namespaces, and no resources shared with container, invisible to it.