What version of Go are you using (go version)?
$ go version
go version go1.13.7 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/amanners/Library/Caches/go-build"
GOENV="/Users/amanners/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/amanners/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.7/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.7/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/5l/sgy31cm96k9671825xjz_sm40000gq/T/go-build492878366=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Attempted to use WMIC/PSRemote to interact with a system to launch a GO executable that logs the current user (aka PSSession user/WMI exec) using user.Current(). User returns as nil with err The system cannot find the file specified. because the user does not have a home directory on the remote system.
Platform: Windows Server 2016 Version 1607 Build 14393.3326
What did you expect to see?
Valid User structure with Dir as nil/empty string.
os/user/lookup_windows.go:184
func newUser(uid, gid, dir, username, domain string) (*User, error) {
domainAndUser := domain + `\` + username
name, e := lookupFullName(domain, username, domainAndUser)
if e != nil {
return nil, e
}
u := &User{
Uid: uid,
Gid: gid,
Username: domainAndUser,
Name: name,
HomeDir: dir, <- should return as empty/nil
}
return u, nil
}
What did you see instead?
No user returned, error stated above.
Extra information
The specific issue resides in how t.GetUserProfileDirectory() is handled in current():
func current() (*User, error) {
t, e := syscall.OpenCurrentProcessToken()
if e != nil {
return nil, e
}
defer t.Close()
u, e := t.GetTokenUser()
if e != nil {
return nil, e
}
pg, e := t.GetTokenPrimaryGroup()
if e != nil {
return nil, e
}
uid, e := u.User.Sid.String()
if e != nil {
return nil, e
}
gid, e := pg.PrimaryGroup.String()
if e != nil {
return nil, e
}
dir, e := t.GetUserProfileDirectory() <- These lines
if e != nil {
return nil, e <- should set directory to nil and continue on
}
username, domain, e := lookupUsernameAndDomain(u.User.Sid)
if e != nil {
return nil, e
}
return newUser(uid, gid, dir, username, domain)
}
In windows environments it is possible to have a login type where the user doesn't have a Home Directory on that system (all remote windows domain administrator tasks). I will submit a PR with a proposed solution to this.
@christophert and I discovered this while trying to start remote tasks on Windows system that we had never logged into.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Attempted to use WMIC/PSRemote to interact with a system to launch a GO executable that logs the current user (aka PSSession user/WMI exec) using
user.Current(). User returns asnilwith errThe system cannot find the file specified.because the user does not have a home directory on the remote system.Platform:
Windows Server 2016 Version 1607 Build 14393.3326What did you expect to see?
Valid User structure with Dir as nil/empty string.
os/user/lookup_windows.go:184What did you see instead?
No user returned, error stated above.
Extra information
The specific issue resides in how
t.GetUserProfileDirectory()is handled incurrent():In windows environments it is possible to have a login type where the user doesn't have a Home Directory on that system (all remote windows domain administrator tasks). I will submit a PR with a proposed solution to this.
@christophert and I discovered this while trying to start remote tasks on Windows system that we had never logged into.