sqlcmd panics when using MSI on App Service

[ardoric]

Running the following command

sqlcmd -d AdventureWorks2023 -S soulnorth.database.windows.net -Q "select count(*) from SalesLT.Product" --authentication-method=ActiveDirectoryManagedIdentity
gets me the following error on App Service:

sqlcmd.exe -d AdventureWorks2023 -S soulnorth.database.windows.net -Q "select count(*) from SalesLT.Product" --authentication-method=ActiveDirectoryManagedIdentity
panic: Unable to get user name

goroutine 1 [running]:
github.com/microsoft/go-sqlcmd/pkg/sqlcmd.(*Sqlcmd).ConnectDb(0xc0002cc3c0, 0x0?, 0x1?)
	D:/a/1/s/pkg/sqlcmd/sqlcmd.go:299 +0xc65
github.com/microsoft/go-sqlcmd/cmd/sqlcmd.run(0xc000006760, 0x1c01080)
	D:/a/1/s/cmd/sqlcmd/sqlcmd.go:761 +0x6e9
github.com/microsoft/go-sqlcmd/cmd/sqlcmd.Execute.func2(0xc000644300?, {0xc000101ce0?, 0x7?, 0x8?})
	D:/a/1/s/cmd/sqlcmd/sqlcmd.go:242 +0x3ce
github.com/spf13/cobra.(*Command).execute(0xc000644300, {0xc000642680, 0x7, 0x8})
	C:/Users/VssAdministrator/go/pkg/mod/github.com/spf13/[email protected]/command.go:920 +0x847
github.com/spf13/cobra.(*Command).ExecuteC(0xc000644300)
	C:/Users/VssAdministrator/go/pkg/mod/github.com/spf13/[email protected]/command.go:1044 +0x3bc
github.com/spf13/cobra.(*Command).Execute(...)
	C:/Users/VssAdministrator/go/pkg/mod/github.com/spf13/[email protected]/command.go:968
github.com/microsoft/go-sqlcmd/cmd/sqlcmd.Execute({0x15dba18, 0x6})
	D:/a/1/s/cmd/sqlcmd/sqlcmd.go:265 +0x1a5
main.main()
	D:/a/1/s/cmd/modern/main.go:52 +0x21f

This seems to happen at a stage after the connection has been established (after sql.OpenDB() has been executed successfully) and the code is just trying to fill out some variables.

In this case it seems to fail after osuser.Current() fails (probably due to sandboxing restrictions on App Services?).

Same command works on a similarly configured VM.

[shueybubbles]

thx for opening an issue!

I was wondering where osuser.Current() could fail, I guess this answers that!
I suppose an empty string for SQLCMDUSER is fine.