ShellExecute is an ancient API with an unusual return signature. It
pretends to return an HINSTANCE for backwards compatibility with Windows
3, but it's actualy a fake HINSTANCE. What's really happening here,
according to MSDN, is that it returns either an Windows error less
than or equal to 32, or it succeeds. So we adjust the return value
accordingly.
Prior to this commit, it was impossible to tell whether this command had
succeeded. For example, when using the "runas" verb, ShellExecute did
not correctly indicate whether or not permission was granted.
Change-Id: Ie60554d6465798bacb9a225c4ead7e8dd62bce14
Reviewed-on: https://go-review.googlesource.com/c/sys/+/199521
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nenad Kozul <knenad@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Changes in syscall_windows.go were copied from
internal/syscall/syscall_windows.go.
zsyscall_windows.go was regenerated by running
'go generate -tags=generate golang.org/x/sys/windows'
using a toolchain built from tip (after CL 196122).
These functions are called by cmd/go/internal/lockedfile via
internal/syscall/windows. I'd like to copy lockedfile into another
project (CL 197299), but these functions need to be exposed here in
order to do so. We may need these in x/mod eventually, too.
Change-Id: I2033106d2ba65009e764591bfe5702f4d41dffdd
Reviewed-on: https://go-review.googlesource.com/c/sys/+/198060
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
There's no point in adding a function call to retrieve a constant, or
worse, a syscall to retrieve a constant. These are fixed and baked so
deep into NT they'll never change. So let's benefit from the obvious
optimization and make these constants. Go easily inlines the function
calls as well. We also take the opportunity to sunset
OpenCurrentProcessToken and restore its original behavior, since users
should be invoking this deliberately with the correct access mask.
Change-Id: I92f7de56c0fcf5b69b59f5a79d2828c7ddf3c8f6
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196800
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
GetCurrentProcess and GetCurrentThread return -1 and -2 respectively. We
could arguably hard code those values, but MSDN cautions not to; I'm
sure this advice is old now, given that the psuedo handles for tokens
(not processes/threads) are now implemented with inline functions in the
headers for Windows 8, but anyway, we'll follow Microsoft's advice.
However, regardless of that, these functions never ever return an error.
MSDN doesn't indicate that they do, reverse engineering the functions
doesn't indicate that they do, and checking against 0 is just plain
wrong, considering 0!=INVALID_HANDLE_VALUE; however
INVALID_HANDLE_VALUE==-1, so that's not correct either. In fact,
checking any value and returning any error does not make sense.
Incidently having to check code for the pseudo handle is more verbose
too.
In order to make this function do the correct thing and meet the spec,
remove the error value from the return.
Change-Id: If03c9dab001be3bf5a04999aef20dbfcf8a4f405
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196798
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This adds the basic foundation for dealing with security descriptors and
access control lists. The basic creators and getters are included in
this patch. These are some of the most fundamental security objects on NT,
and any work with the security API is fairly limited without it. These
are "core" NT structures.
Change-Id: I9a6399cb6ee41a825de30d5364ab69102d5f6d57
Reviewed-on: https://go-review.googlesource.com/c/sys/+/195498
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Windows type PBOOL is a pointer to a 4 byte value, where 0 means false
and not-0 means true. That means we should use uint32 here, not bool,
since Go bools can be 1 byte. This commit was re-generated using
mksyscall_windows.go from CL 196122.
Updates: golang/go#34364
Change-Id: I8e83b9a09c0b58d14ac9a7dee316553940ac6ee3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/196123
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
There are a few functions to control the behavior of shutdown and
logout, both for what the current process does during shutdown, and also
whether or not the current process is running in an interactive session.
The below code is a port of the MSDN example code to Go using one of the
added new functions:
https://docs.microsoft.com/en-us/windows/win32/shutdown/how-to-shut-down-the-system
func shutdownLikeMSDNDoes() error {
seShutdownName, err := windows.UTF16PtrFromString("SeShutdownPrivilege")
if err != nil {
return err
}
var shutdownPriv windows.Tokenprivileges
err = windows.LookupPrivilegeValue(nil, seShutdownName, &shutdownPriv.Privileges[0].Luid)
if err != nil {
return err
}
shutdownPriv.Privileges[0].Attributes = windows.SE_PRIVILEGE_ENABLED
shutdownPriv.PrivilegeCount = 1
process, err := windows.GetCurrentProcess()
if err != nil {
return err
}
var token windows.Token
err = windows.OpenProcessToken(process, windows.TOKEN_ADJUST_PRIVILEGES | windows.TOKEN_QUERY, &token)
if err != nil {
return err
}
defer token.Close()
err = windows.AdjustTokenPrivileges(token, false, &shutdownPriv, 0, nil, nil)
if err != nil {
return err
}
err = windows.ExitWindowsEx(windows.EWX_SHUTDOWN | windows.EWX_FORCE,
windows.SHTDN_REASON_MAJOR_OPERATINGSYSTEM | windows.SHTDN_REASON_MINOR_UPGRADE | windows.SHTDN_REASON_FLAG_PLANNED)
if err != nil {
return err
}
return nil
}
Note, though, that this function doesn't set the token privs back to how
they were before, which isn't good. A more robust method than the MSDN
one above would be to duplicate&impersonate.
Fixes: golang/go#34271
Change-Id: Ibe55ddd35b709d9ab793cb9af47c39901c5e5c69
Reviewed-on: https://go-review.googlesource.com/c/sys/+/195497
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bruce Downs <bruceadowns@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Indeed Go has mutexes of its own, but these are considerably
different from the native Windows ones, that can work across processes
and be put in various namespaces. They're an essential part of Windows
systems programming and important for interfacing with various external
interfaces.
Change-Id: I03987800ed1c134442321678c2c7d7aa359ecb36
Reviewed-on: https://go-review.googlesource.com/c/sys/+/192497
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Go runtime disables priority boosting because it interferes with the
scheduler timer threads in some cases. But some apps might want to
re-enable it for specific reasons, so this commit adds the function to
do so.
Change-Id: Ida68b9f2b188560b46c322197461dd06453329e2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/191839
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
While RtlGetVersion was added so that users can get the Windows version
that isn't affected by manifesting, RtlGetVersion is still stubbed out
by the application compatibility layer (aclayers.dll and apphelp.dll)
for certain processes, such as msiexec.exe, rendering these functions
useless for actually determining the underlying operating system. This
matters in the case of msiexec.exe using a custom action DLL to install
a kernel driver, which of course is version specific. This is also
useful, it turns out, for the C runtime library, in which Microsoft uses
this function too. It's existed as a stable interface since Windows XP,
has Wine support, and is used in a decent amount of software.
Change-Id: If391e43bc6d798eff6803d5a7aa6a179f2b31d88
Reviewed-on: https://go-review.googlesource.com/c/sys/+/188119
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Other functions, like GetVersion(), will lie about the OS version
depending on various win32 and manifest compatibility shims in place.
Calling RtlGetVersion is the proper way to retrieve the true OS version.
Change-Id: I2bd6d097dd763df51617cd825dc0ad300abf6212
Reviewed-on: https://go-review.googlesource.com/c/sys/+/182718
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This adds the recommended API for determining well-known folder paths,
such as where to place application configuration data. The MSDN
documentation mentions an optimization for the "current user" by passing
NULL as the token, so we provide both variants.
Updates golang/go#32248
Change-Id: I4a2d5d833543e6a0ba8f318944dd6493a0ec31d3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/181637
Reviewed-by: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The SCM can be locked by NT. While traditionally any process could lock
the SCM using "LockServiceDatabase", Microsoft removed this
functionality because it created so many bugs, and that function now
does nothing. However, the system itself, via the "NT Service Control
Manager", is still allowed to lock the SCM.
For example, at boot time on Windows 8.1, the SCM is locked after a
service is started until that service reports itself in a running state.
This poses a bit of a problem: it's useful to install device drivers
from inside services as part of their initialization, and mark the
service as having started only after the device has installed. But
device installation might potentially load new drivers, and drivers
themselves exist as a special type of service. This means that if a
driver is installed before marking the service as started, the entire
SCM will deadlock, and the OS will be partially unresponsive for a
minute or two.
Fortunately Microsoft supplies an API for exactly this purpose. The
solution is to mark the service as started before installing device
drivers, only under the circumstance that the SCM is locked. So, this
commit adds the proper API for determining this. It can be used like
this:
if m, err := mgr.Connect(); err == nil {
if lockStatus, err := m.LockStatus(); err == nil && lockStatus.IsLocked {
log.Printf("SCM locked for %v by %s, marking service as started", lockStatus.Age, lockStatus.Owner)
changes <- svc.Status{State: svc.Running}
}
m.Disconnect()
}
deviceDriver.Install()
This creates messages like the following, indicating that this API
works:
SCM locked for 1s by .\NT Service Control Manager, marking service as started
Change-Id: Ic2f5b387e23efc3a287b2ab96ff84b357b712e36
Reviewed-on: https://go-review.googlesource.com/c/sys/+/180977
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This corrects the Windows int type to be the more correct int32 Go
analog, as well as not using GetLastError() for the error value of the
GUID string parsing function.
Change-Id: I9716f991ef649f7d299295e3f4e75d3986ec3a74
Reviewed-on: https://go-review.googlesource.com/c/sys/+/181397
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Virtually every project that works with x/sys/window's GUIDs winds up
rolling their own version of this in one way or another. So let's add
the correct win32 wrappers for it, so that these are always generated,
parsed, and converted in the uniform correct way.
Change-Id: I35f4b4ab5fc681d3e16fc5bbaf2cb20031eb3f12
Reviewed-on: https://go-review.googlesource.com/c/sys/+/180938
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I realize that at this time, x/sys/windows is most certainly not aiming
to be some sort of UI library or anything remotely close to that.
However, MessageBox is sort of the one universal Windows API that's used
even for console programs. It's *the* classic debugging helper. It's
even pretty customary for console programs to display their usage
message in a message box rather than stdout. I realize this might be
somewhat disturbing to consider if you're in the blissful Unix utopia,
but on Windows, this is just sort of how things roll. Easy access to
MessageBox() is important.
Change-Id: I16183b69e8a27a5ddaf73d1d4e106bb7b201a6f0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178899
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is the way to do things like execute a process elevated with UAC
and interact with that whole system. It turns out to be quite important
for writing Windows software.
Change-Id: I5e05dc9b89ea308d42ac86ba563fd01922fc940c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/178898
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These allow actual inspection of SIDs. For example, it might be
desirable to iterate through the group SIDs in order to find one set by
SERVICE_CONFIG_SERVICE_SID_INFO:
for _, g := range groups {
if g.Attributes != windows.SE_GROUP_ENABLED|windows.SE_GROUP_ENABLED_BY_DEFAULT|windows.SE_GROUP_OWNER {
continue
}
if !g.Sid.IsValid() {
continue
}
if g.Sid.IdentifierAuthority() != windows.SECURITY_NT_AUTHORITY {
continue
}
if g.Sid.SubAuthorityCount() < 6 || g.Sid.SubAuthority(0) != 80 {
continue
}
sid = g.Sid
break
}
Another usage of the APIs added would be to find if a user is in the
administrator group with either an elevated or unelevated token:
isAdmin := false
for _, g := range groups {
if g.Attributes&(windows.SE_GROUP_ENABLED|windows.SE_GROUP_USE_FOR_DENY_ONLY) == 0 {
continue
}
if !g.Sid.IsWellKnown(windows.WinBuiltinAdministratorsSid) {
continue
}
isAdmin = true
break
}
Change-Id: I8f8dc8d37b71ec58fd51e21ea1f1b3aada6d66b0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177841
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
The GetCurrent*Token variety of functions are actually implemented as
inline functions in the header files of the SDK. Attempting to call out
to these as library functions is an error. This commit also adds a test
to ensure that these work as expected.
Change-Id: I105f1ca1a8936114fe61bc22188200c31f240a23
Reviewed-on: https://go-review.googlesource.com/c/sys/+/177840
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The svc package exposes svc.SessionChange, but it's impossible to do
anything with them without these structures, and without being able to
enumerate them prior to events, the events themselves aren't useful, so
we add the enumeration functions as well.
Change-Id: I14c932dfe97c6712fd4868c1b3a0e3a61a6a562c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/176623
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This lays the groundwork for service notification and tracking by adding
the required API functions. Users can make notifiers directly using it,
or later if we're feeling ambitious, we can see if we can come up with a
generalized solution in x/windows/svc.
Change-Id: I80503cc27970fbb23bf17cd8bc50eaa7787aa6bd
Reviewed-on: https://go-review.googlesource.com/c/sys/+/176624
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These are extremely useful functions and core to the Windows security
API. They are so useful, in fact, that most of these were taken right
out of the Go repo's internal/syscall/windows package.
Change-Id: I13e34b830dd60f59fcae8085ae2be189d9cc9282
Reviewed-on: https://go-review.googlesource.com/c/sys/+/176625
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We already have all the structs and constants for async I/O, and the
various functions of x/sys/windows take the right parameters. But we're
missing the final step of any ordinary async I/O routine: getting the
result of overlapped I/O. Without this, the rest of the plumbing
supported by this module isn't actually so useful. So add this small
oversight.
Change-Id: I0ce1a71bce06bc81a83f3b0ca10ad9c4b67af726
Reviewed-on: https://go-review.googlesource.com/c/sys/+/168521
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The security API is already quite extensive, but for some strange
reason, this essential and useful function was left out of the initial
port. So, we add it here, along with the relevant constants and a test
case.
Change-Id: I99568703565addf15603480f11b0edafdfc1718f
Reviewed-on: https://go-review.googlesource.com/c/sys/+/167378
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The %WINDIR% variable is an odd choice and not even entirely reliable.
Since Windows 2000, there has been a specific function for determining
this information, so let's use it. It's also a useful function in its
own right for folks who want to launch system tools in a somewhat safe
way, like netsh.exe.
Updates golang/go#14959
Updates golang/go#30642
Change-Id: Ic24baf37d14f2daced0c1db2771b5a673d2c8852
Reviewed-on: https://go-review.googlesource.com/c/sys/+/165759
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
