Question: Possible running secret-service in WSL2
ryan-dyer opened this issue · 4 comments
Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.
If you have a feature request, please post to the UserVoice.
If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.
Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".
Please fill out the below information:
-
Your Windows build number: (Type
ver
at a Windows Command Prompt)
Microsoft Windows [Version 10.0.18922.1000] -
What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
Attempting to get gnome-keyring working in WSL2.
Running:
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
I have installed dbus, libsecret-1.0, libsecret-tools, and gnome-keyring.
Specifically I am trying:
secret-tool store --label=test key value
Password:
** Message: 12:19:21.107: Remote error from secret service: org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login
secret-tool: No such interface 'org.freedesktop.Secret.Collection' on object at path /org/freedesktop/secrets/collection/login
-
What's wrong / what should be happening instead:
Would assume I should be able to store the secret. Ultimately I'm attempting to use secret-service as the backend for aws-okta (https://github.com/segmentio/aws-okta). -
Strace of the failing command, if applicable: (If
some_command
is failing, then runstrace -o some_command.strace -f some_command some_args
, and link the contents ofsome_command.strace
in a gist here).
https://gist.github.com/ryan-dyer/8cd8fe458139475f1f8b495fe99f42a6 -
For WSL launch issues, please collect detailed logs.
See our contributing instructions for assistance.
The usual dbus
session goodness that is normally in place with a common Ubuntu graphical install with xdm/gdm/lightdm
(or similar) isn't in place with a (typical) WSL setup. You've also have no systemd-logind
alive.
Your question is basically this reddit.
I made an effort to prove that answer wrong (it is) but too lazy on a Canada Day to take it to completion. Including as far as I got here for posterity so I don't lose it. Maybe someone highly motivated will iterate.
Other way to go is get systemd
running (ref #994) and fire up xrdp
. After logging into the session, you'll almost certainly get a nice pretty credentials popup out of secret-tool
, because gnome-keyring-daemon
will be living in its happy place.
Calling defeat for the day on a CLI solution tho. Bonne chance.
@therealkenc thanks for taking a shot at this. I tried following along with your solution, but ran into one issue after another, and I don't have the knowledge base to make it further than you did.
My frustrations follow.. I'm not sure why we need all that just to store a password securely. For now, I think my script will just have to prompt each time for the password. It was curious to me why plain text netrc files were a thing, and they unfortunately make some sense given the state of things...
From all the research I've done, this seems to be an issue with using secret-tool on any headless Linux system (but I could be wrong). If that's the case, it's quite shocking that a command line only solution for something as basic as credential storage doesn't exist. I also tried using the python3 keyring module, but that had it's own issues, and I suspect it'd ultimately boil down to the same errors that secret-tool runs into, since the python keyring uses the same secret service api.
Calling defeat for the day on a CLI solution tho. Bonne chance.
The OP scenario works out of the box with WSLg. It would be a pretty deep rabbit hole to get a text-based (tty) keyring password prompt set up. I am sure it can be done; people probably do it with cloud scenarios. Punt getting that much working on WSL to discussion as it is a userspace thing. There wasn't a WSL actionable on this one, notwithstanding feature-request GUI solution gnome-keyring. If you fire up Firefox (or similar) you get the same sort of keyring prompt.