You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently as part of work to sandbox a subprocess, the Nomad team at HashiCorp needed to add a SECURITY_CAPABILITIES struct to the StartupInfoEx for a process. Because this is not exposed in SysProcAttr this involved writing an unfortunate amount of code, much of which had to be simply lifted from the os/exec stdlib. See helper/winexec/create.go
Implementation Notes
Previously a proposal was implemented to add a ParentProcess field to SysProcAttr for Windows #44011. This was discussed around the same time as a rejected proposal to add the full StartupInfoEx struct #44005.
One of the reasons why the StartupInfoEx proposal was rejected was because it resulted in ambiguity around how one would merge any default attributes with ones provided by the user. There are two options to work around this:
Option 1: Extensible
Our implementation referenced above adds a ProcThreadAttributes field to the forked os/exec.Cmd which is a slice of ProcThreadAttribute. This instead could be added to SysProcAttr as an extensible way of adding more attributes:
type SysProcAttr struct {
// ...
ProcThreadAttributes []ProcThreadAttribute
}
type ProcThreadAttribute struct {
Attribute uintptr
Value unsafe.Pointer
Size uintptr
}
When the StartupInfoEx struct is built, we call newProcThreadAttributeList with a count of len(ProcThreadAttributes) + 2 (taking the default attributes from syscall/exec_windows.go). Any ProcThreadAttributes that come from the user override those defaults if using the same Attribute field, which makes for unambiguous behavior.
Option 2: SecurityAttributes only
An alternative would be to add a SecurityCapabilities field to SysProcAttr and
Thanks for submitting this proposal. IMO supporting security capabilities would be a good addition.
Some comments:
The concern in #44005 was that attributes set by the user could conflict with parameters and attributes set by syscall.StartProcess, and some conflicts might not be possible to reconcile. The conclusion was that we want to curate which attributes are allowed to be set by the user so syscall.StartProcess is always coherent. This discards the option 1.
An alternative would be to add a SecurityCapabilities field to SysProcAttr and
This seems like the way to go. All new types and properties should be defined in the syscall package, not in x/sys/windows, as it is what os/exec uses under the hood. I've modified a bit your proposed API to fit better in syscall:
package syscall
typeSecurityCapabilitiesstruct {
AppContainerSid*SIDCapabilities*SIDAndAttributesCapabilityCountuint32Reserveduint32
}
typeSysProcAttrstruct {
...SecurityCapabilities*SecurityCapabilities// if set, applies these security capabilities to the new process
}
Makes sense to me! I should have noted in the original proposal that I/we are happy to contribute this patch. What's the next step at this point? Should we submit the patch along the lines above or should we submit a design doc?
Makes sense to me! I should have noted in the original proposal that I/we are happy to contribute this patch. What's the next step at this point? Should we submit the patch along the lines above or should we submit a design doc?
We need to wait for this proposal to be discussed by the proposal committee, see the-proposal-process. There is no need for a design doc, the changes are simple enough. I would recommend holding your patch till the proposal is approved.
Proposal Details
Allow adding Security Capabilities to
SysProcAttr
on Windows. Note this is separate from the existingSecurityAttributes
struct which can be set as theProcessAttributes
orThreadAttributes
field.Motivation
Recently as part of work to sandbox a subprocess, the Nomad team at HashiCorp needed to add a
SECURITY_CAPABILITIES
struct to theStartupInfoEx
for a process. Because this is not exposed inSysProcAttr
this involved writing an unfortunate amount of code, much of which had to be simply lifted from theos/exec
stdlib. Seehelper/winexec/create.go
Implementation Notes
Previously a proposal was implemented to add a
ParentProcess
field toSysProcAttr
for Windows #44011. This was discussed around the same time as a rejected proposal to add the fullStartupInfoEx
struct #44005.One of the reasons why the
StartupInfoEx
proposal was rejected was because it resulted in ambiguity around how one would merge any default attributes with ones provided by the user. There are two options to work around this:Option 1: Extensible
Our implementation referenced above adds a
ProcThreadAttributes
field to the forkedos/exec.Cmd
which is a slice ofProcThreadAttribute
. This instead could be added toSysProcAttr
as an extensible way of adding more attributes:When the
StartupInfoEx
struct is built, we callnewProcThreadAttributeList
with a count oflen(ProcThreadAttributes) + 2
(taking the default attributes fromsyscall/exec_windows.go
). AnyProcThreadAttributes
that come from the user override those defaults if using the sameAttribute
field, which makes for unambiguous behavior.Option 2: SecurityAttributes only
An alternative would be to add a
SecurityCapabilities
field toSysProcAttr
andIt would then be up to
syscall/exec_windows.go
to create the appropriate attributes forStartupInfoEx
, as we do already for the parent handle, etc.The text was updated successfully, but these errors were encountered: