Thursday 8 February 2024

Why can't keyctl read my keys under tmux or screen sometimes, error: keyctl_read_alloc: Permission denied

 Another of my self-answered stackoverflow questions.

Apparently randomly sometimes, under screen or tmux, I can't read user keys from @u, I can read from other terminals, even keys that I just added:

When it works:

 $ keyctl pipe $(keyctl padd user test @u <<<"test messsage")
 test messsage

When it fails:

$ keyctl pipe $(keyctl padd user test @u <<<"test messsage")
keyctl_read_alloc: Permission denied

What causes this, how can I fix or prevent it?

How do I read/store a password in a possibly locked gnome-keyring-manager from the shell without breaking existing gnome-keyring-manager clients?

 Another of my stackoverflow self-answered questions 

I want to use secret-tool and gnome-keyring-daemon from a shell session, to store and retrieve passwords. The shell session might be gnome-terminal under the X console, or independently of whether or not I also have an X login, it might be an ssh session or text login.

I do not want gnome-keyring-daemon prompting to unlock a keyring on some remote X session, I do not want it to prompt unlocking of a keyring at all.

If there is an unlocked keyring (e.g. an X console session) then I want to use that keyring session, but if not, then I don't want to unlock an existing keyring as that could interfere with the available credentials of that X session, instead I want to run a private instance of gnome-keyring-daemon just long enough to get the secret, without interfering with any existing clients of any existing gnome-keyring-daemon (e.g. seahorse, chrome, evolution, ssh-agent -- I don't want suddenly asking for ssh keys because something called gnome-keyring-daemon --replace).

And I want to do it from the command line with without perl and python tools.

Many solutions make use of gnome-keyring-daemon --unlock --replace which isn't an option as it destroys the relationship of existing clients.