SNOW-1552759: Super annoying warning message from gosnowflake every invocation of Hashicorp vault cli under sudo

[DrDaveD]

This message is displayed every time the Hashicorp vault-1.17.2 cli is invoked under sudo to root, at least on RHEL8:

WARN[0000]log.go:244 gosnowflake.(*defaultLogger).Warn DBUS_SESSION_BUS_ADDRESS envvar looks to be not set, this can lead to runaway dbus-daemon processes. To avoid this, set envvar DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus (if it exists) or DBUS_SESSION_BUS_ADDRESS=/dev/null.

This message comes from gosnowflake and was reported in vault at hashicorp/vault#22560 but that issue was closed saying to report here instead. Most of the questions in the standard gosnowflake issue template aren't relevant, but this was compiled with go version 1.22.5, and the go.mod for vault-1.17.2 says it is using github.com/snowflakedb/gosnowflake v1.10.0.

When logged in with ssh to a RHEL8 linux server, DBUS_SESSION_BUS_ADDRESS is set so the warning is not emitted, but the variable does not carry over to sudo -s so it is emitted there. However I have never seen any evidence of extra dbus-daemon processes when running vault from sudo -s on Rocky8 or Alma8. There is a dbus-daemon process running on the system as the dbus user and that gets detected by the code added in #1058 so the message is emitted. I tried to reproduce the original problem by unsetting DBUS_SESSION_BUS_ADDRESS and removing $XDG_RUNTIME_DIR/bus but I did not get any extra dbus-daemon processes with either vault or by running select1.go as suggested in #773. Maybe I'm not running the latter test right; it required setting values for SNOWFLAKE_TEST_{ACCOUNT|USER|PASSWORD} which I set to arbitrary values and it just seemed to hang then when I did go run cmd/select1/select1.go in a clone of this git repository.

So the message is warning about a non-existent problem as far as I can see, and very annoying. I build an rpm for vault that is used by about a half-dozen other people and I'd rather not have to explain all this to all of them. I guess I will need to add a patch to vault to add DBUS_SESSION_BUS_ADDRESS=/dev/null into its environment when the variable isn't set, but I didn't want to do that without reporting the issue here at least, as was suggested in the vault issue. Maybe this warning should be avoided when running as root, but on the other hand since I can't reproduce the runaway dbus problem at all I'm not sure whether it might happen in some situations as root for some people too.

[sfc-gh-dszmolka]

hey - thanks for reporting the issue here and sharing the details. Indeed this is nothing but a single logline emitted, nothing else happens. Will look into this.

[sfc-gh-dszmolka]

• short term 'fix' will be available under SNOW-1552759 Remove attempt to detect DBUS_SESSION_BUS_ADDRESS and emitting warning message (revert #1058 except the doc changes) #1184
• proper fix is tracked under SNOW-1553756: SNOW-1017659 replace github.com/99designs/keyring with a different implementation #1183

[DrDaveD]

For now my workaround is to put an sh wrapper around vault in my rpm to set DBUS_SESSION_BUS_ADDRESS=/dev/null if the variable isn't set. I first tried a go patch but failed to figure out how to get the workaround code to run before the gosnowflake warning.

[sfc-gh-dszmolka]

change at #1184 is merged and will be part of the next gosnowflake release

[sfc-gh-dszmolka]

released with gosnowflake v1.11.0 in July 2024