CC @alexbrainman @mattn @zx2c4

Can you suggest exactly what fields would be added to syscall.SysProcAttr, and how they would be documented? Thanks.

I'm pretty familiar with these APIs and can probably do that but... what are you actually trying to accomplish? Most folks should probably not be passing password strings and such around. Do you have a use case in mind?

I'm playing with the idea of improving the nomad raw_exec driver to somehow use non-administrator/system accounts. One of that ways is to use CreateProcessWithLogon; others are to somehow use Group Managed Service Accounts and/or Local Service Accounts (these do not have a user managed password, as such, are more convenient to use; but these seem to require the application to run (or be wrapped) as a Windows service).

I don't know too much about that, so I might be guessing incorrectly at some of the details. It sounds like you have a system service running highly privileged, and you'd like it to create processes running as less privileged users, as specified through a configuration file? And this should be done non-interactively? So sort of like the equivalent of the unix idiom:

if (!fork()) {
    setuid(1001);
    setgid(1001);
    execve(....);
}

Is that what you're after?

Its exactly that :-)

Nomad is running as a windows service (under the SYSTEM account) and acting as a init/service manager (akin to systemd) for the processes its starts as child processes; that is, it launches the process as a child process, captures their output as logs, re-launches then when they die, etc.

Gotcha, okay. So in that case, if you're already running as Local System, you don't want to use these APIs that require a password. Rather, mint a token using something like NtCreateToken, and then pass that to the Token field:

attrs := &os.ProcAttr{
                Sys: &syscall.SysProcAttr{
                        Token: syscall.Token(theTokenThatYouJustMade),
                },
}

And then attrs is passed to os.StartProcess like usual.

Given that os.StartProcess already takes a token to support this use case, I'm not sure there's anything required of the actual Go runtime here, so maybe this can be closed?

Interesting! So we can mint any user token, load its profile, and start the process?

If so, I think that the only thing missing is an example of this in the documentation 🙂

Interesting! So we can mint any user token, load its profile, and start the process?

If you're running as Local System, then yep, pretty much.

If so, I think that the only thing missing is an example of this in the documentation

I don't think it's the job of Go's documentation to provide walkthroughs of how to use rarely used NT APIs, especially ones involving manual token creation.

Thank you! I will try to get it working.