☰

如何获取 gnome-keyring 的 .service 文件？

tag-icon • tag-icon linux dbus gnome-keyring
如何获取 gnome-keyring 的 .service 文件？

我的最终目标是让 gnome-keyring 充当 RHEL 6 服务器上的 shell 和 python 脚本使用的凭证存储。管理员安装了软件包 gnome-keyring-2.28.2-8.el6_3.x86_64，gnome-keyring-daemon 确实启动了。

当我尝试从 Python 访问它时，我收到一个错误The name org.freedesktop.secrets was not provided by any .service files

使用 Google 搜索该错误会返回许多问题，这些问题可以通过“安装 gnome-keyring”解决，但这已经在该系统上完成了。

我不确定我正在查看的是配置问题、旧版本问题还是其他问题。

编辑：@grawity 的回答总体上增加了不少清晰度。我怀疑你对 gnome keyring 的看法是对的，因为我正在做的是：

启动 gnome-keyring-daemon 进入 dbus 会话：dbus-run-session -- gnome-keyring-daemon --start

导出 GNOME_KEYRING_SOCKET、SSH_AUTH_SOCK、GNOME_KEYRING_PID

启动 shell 进入 dbus 会话：dbus-run-session -- bash

导出DBUS_SESSION_BUS_ADDRESS

调用 python-keyring 并让它列出找到的后端：pipenv run python -m keyring --list-backends

答案1

D-Bus.service文件对于自动“按需”激活服务必不可少。但有些文件并非如此意味着按需激活 – 相反，它们应该由桌面环境或 PAM 模块等明确启动。一旦以这种方式启动，gnome-keyring-daemon 将声明总线名称，而无需 .service 文件。

真正的问题可能在于程序连接GNOME Keyring。它不是系统服务；它是每个用户的服务，但可以通过 D-Bus“会话总线”访问，顾名思义，它通常是每个会话的。（尽管这种情况最近有所改变，许多 Linux 发行版都转向了“用户总线”模型，但从 RHEL 6 的角度来看，这仍然是遥远的未来。）

当 gnome-keyring-daemon 启动时，它会连接到它认为是“当前”的会话总线（即 $DBUS_SESSION_BUS_SOCKET 中设置的总线），并在该总线上声明一个名称。但是，如果您的其他 SSH 会话没有此环境变量，它们将无法找到正确的总线（在最坏的情况下，它们将启动一个新的每次创建一个 session.bus 实例）。

因此，根据您启动 gnome-keyring-daemon 的方法，您可能还想手动启动实例dbus-daemon --session（使用dbus-run-session或dbus-launch），并且您需要确保属于该用户的所有 SSH 会话都知道相同的 $DBUS_SESSION_BUS_SOCKET。例如，启动守护进程后，您可以将环境变量存储在 ~/.dbus.env 中，其他 SSH 会话会自动从其 ~/.profile 等中“获取”这些变量。

作为参考，如果守护进程由 pam_gnome_keyring 启动（与 GNOME 一样），并且您不是在此机器上使用 pam_systemd（在 RHEL 6 上可能不存在），初始化过程分为两个阶段，工作方式如下：

  1. PAM 经过“open_session”阶段并运行gnome-keyring-daemon --daemonize --login。
  2. 守护进程在某处打开一个“控制”Unix套接字。
  3. 桌面环境通过启动会话总线dbus-launch并导出 $DBUS_SESSION_BUS_SOCKET 以供所有程序使用。
  4. 桌面环境调用gnome-keyring-daemon --start，它使用控制套接字将 $DBUS… 变量的内容通知给密钥环守护进程。
  5. 密钥环守护进程连接到会话总线并声明org.freedesktop.secrets总线名称。

相关内容