aws-vault fails with `specified keyring backend not available` when using `kwallet` without specifying the `--backend` flag

[Mr-istov]

Hello, until a few days ago while using aws-vault v5.4.0 I didn't had any problems running aws-vault with kwallet as a backend without specifying the --backend flag, but after upgrading to v6.1.0 it started throwing me the following error:

aws-vault: error: Specified keyring backend not available, try --help

This is the output with the --debug flag:

2020/10/09 17:29:23 [keyring] Considering backends: [secret-service]
2020/10/09 17:29:23 [keyring] Failed backend secret-service: The name org.freedesktop.secrets was not provided by any .service files
aws-vault: error: Specified keyring backend not available, try --help

If I run aws-vault with specifying the --backend=kwallet flag it seems that it works, but I wonder why I didn't had this problem before, was this changed with the upgrade somehow?

• [ ] I am using the latest release of AWS Vault
• [ ] I have provided my .aws/config (redacted if necessary)
• [x] I have provided the debug output using aws-vault --debug (redacted if necessary)

[gdamjan]

the regression has been introduced with this change: https://github.com/99designs/aws-vault/commit/7572b93daed03c44a3b984913bced6ebdb2dca80#diff-83de63909ead282862b13050fe347d68

removing the Default(backendsAvailable[0]). line fixes the issue - by not specifying a backend, and allowing keyring to find it automatically.

[Mr-istov]

@mtibben Was there a reason as to why was that line added, and if it is not required, could it be removed?

[mtibben]

AWS Vault should be able to tell you what backend it's going to use before it does - the "fallback" behaviour is good when when determining what default to display, but is not desirable when actually executing. If keyring is not returning available backends correctly, the problem is likely there.

[gdamjan]

In both cases aws-vault reports available backends and their order…
(v6.1.0):

  --backend=secret-service   Secret backend to use [secret-service kwallet pass file] ($AWS_VAULT_BACKEND)

patched with #672:

  --backend=BACKEND          Secret backend to use [secret-service kwallet pass file] ($AWS_VAULT_BACKEND)

the problem is that the Default(backendsAvailable[0]). line in aws-vault tells keyring to fix the backend to just that one, which actually limits what keyring is capable of.

[Mr-istov]

As @gdamjan mentioned the Default(backendsAvailable[0]). seems to be causing the keyring to only consider the secret-service backend on Linux.
The code at fault seems to be here in globals.go when trying to open the keyring:

if a.keyringImpl == nil {
        if a.KeyringBackend != "" {
            a.KeyringConfig.AllowedBackends = []keyring.BackendType{keyring.BackendType(a.KeyringBackend)}
        }
        var err error
        a.keyringImpl, err = keyring.Open(a.KeyringConfig)

And then here in keyring.go:

if cfg.AllowedBackends == nil {
        cfg.AllowedBackends = AvailableBackends()
    }
    debugf("Considering backends: %v", cfg.AllowedBackends)

Since we make the default value of the a.KeyringBackend to be secret-service the value for the AllowedBackends here:
a.KeyringConfig.AllowedBackends = []keyring.BackendType{keyring.BackendType(a.KeyringBackend)} will make it be to [secret-service] , and it will not enter in the if statement which lists all the available backends since AllowedBackends is not nil

[mtibben]

Yes that behaviour is intentional @gdamjan and @Mr-istov. Allowing the keyring to "fallback" is confusing, and results in lost credentials. See this keyring issue https://github.com/99designs/keyring/issues/74#issue-667687286. We want to remove this behaviour from keyring altogether.

Instead keyring should determine at runtime which backends _can_ be used, and aws-vault should specify _which_ to use

[gdamjan]

But then aws-vault defaults to 'secret-service' which is not even available on my system, instead of using 'kwallet' as it used before.

[mtibben]

See my earlier comment

If keyring is not returning available backends correctly, the problem is likely there.

[Mr-istov]

Instead keyring should determine at runtime which backends _can_ be used, and aws-vault should specify _which_ to use

Hmm well if that's the case if I may suggest, maybe it would be better to make the --backend flag required if the env var AWS_VAULT_BACKEND is not specified.
That way instead of forcing aws-vault to choose secret-service for a default backend for Linux, it will require the wanted backend to be specified with the env var or by the flag. That can be accomplished with the kingpin package:

Envar("AWS_VAULT_BACKEND").
Required().
EnumVar(&a.KeyringBackend, backendsAvailable...)

[mtibben]

If secret-service isn't available, keyring shouldn't make that option available. I'm pretty sure secret service availability can be determined by a dbus call

[Mr-istov]

@mtibben Yeah that seems understandable. This issue seems to be more applicable in keyring.
After some investigating seems that the problem is when initializing the keyring package, the secret-service seems to be added to the supportedBackends and the error is thrown when we try to open the keyring. I guess the best way would be, before adding secret-service backend to the supportedBackends there should be a check if that DBus service exists, I'm just not sure where that check would be more applicable, in keyring or go-libsecret

Since this issue is not relevant to aws-vault I plan on closing this issue and the associated PR and re-open them in keyring if there are no objections?