Another of my self-answered stackoverflow questions.
https://stackoverflow.com/questions/77961854/why-cant-keyctl-read-my-keys-under-tmux-or-screen-sometimes-error-keyctl-read/77961855#77961855
Another of my self-answered stackoverflow questions.
https://stackoverflow.com/questions/77961854/why-cant-keyctl-read-my-keys-under-tmux-or-screen-sometimes-error-keyctl-read/77961855#77961855
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?
Another of my stackoverflow self-answered questions
https://stackoverflow.com/questions/77962998/how-do-i-read-store-a-password-in-a-possibly-locked-gnome-keyring-manager-from-t/77962999#77962999
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.