-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass file handle to execd on windows #164
Comments
I like the env var handle approach, though I wonder if something like a named pipe - which are supported in Golang in Microsoft's winio package or otherwise through standard Windows APIs - could be closer to the intuitiveness of basic parent/child process demo: https://github.com/micahyoung/winio-named-pipes-explore container.d winio usage: https://github.com/containerd/containerd/blob/master/cio/io_windows.go#L52 It does appear possible to set permissions and write-only functionality on the name pipe as well. Also, my demo suggests that Update: After playing around with both approaches a bit, I'm more in favor of the original handle-as-env-var approach. The go code to parse and process the env var isn't too onerous and the security model is much better - the named pipes would be global to the OS and the SDDL format for securing them isn't amendable to a single process group. There's also concurrency questions about allowing multiple processes to write to that pipe. To mitigate some of the UX issues, perhaps optional helper executables/libraries can be created to be used by the exec.d executables to simplify setting env vars, which could hide away both the |
FWIW, as I bet you did, I searched around to see if there's any more idiomatic-equivalents of FD 3 and there doesn't appear to be any. I also checked to see what was done with Cloud Foundry launcher which does inherit the parents handles, but given how different the use-cases are here, it didn't feel relevant. |
@micahyoung thanks for looking into this! |
Resolved by #203 |
Oops, got ahead of myself there. #203 hasn't merged yet |
Resolved by #203 (for realz this time) |
In our current exec.d specification we expect the lifecycle to provide a file descriptor at index 3 in the child's file descriptor table, to which the child is expected to write it's output.
On windows a child may inherit an additional file handle (if configured properly by the parent), however that handle will not be associated with file descriptor 3 unless we use undocumented features of the windows
CreateProcess
syscall that are not exposed by the go stdlib.Background from the python docs
While we could potentially work around this. It seems like the more natural pattern on windows is to pass the file handle (a
uint32
) to theexec.d
process either as a positional argument or an environment variables. I propose we pass the hex representation of the file handle to theexec.d
process in an environment variable namedCNB_EXEC_D_HANDLE
.More background:
The text was updated successfully, but these errors were encountered: