search

nix-community / home-manager

Manage a user environment using Nix [maintainer=@rycee]
https://nix-community.github.io/home-manager/
MIT License
6.36k stars 1.7k forks source link

gnome-keyring doesn't work when home-manager handles the X session #1454

Open DamienCassou opened 3 years ago

DamienCassou commented 3 years ago

Issue description

I have

{
  services.gnome-keyring.enable = true;
  xsession = {
    enable = true;
    windowManager.i3.enable = true;
  };
}

Gnome keyring doesn't work:

gnome-keyring-daemon: insufficient process capabilities, insecure memory might get used
couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.keyring.SystemPrompter was not provided by any .service files

Meta

Maintainer CC

/cc @rycee

Technical details

workflow commented 3 years ago

Same here, and I also can't get the home-manager provided gnome-keyring to run.

The first warning comes from here and I believe it means a potential security problem in that the keys could be written to swap (if you have an unencrypted swap). I wonder if it's even a good idea to run gnome-keyring as non-root?

Update: The nixos-module seems to handle this like this

stale[bot] commented 3 years ago

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

dotlambda commented 3 years ago

Still relevant.

berbiche commented 3 years ago

Few things:

Process capabilities can be set in the systemd service (AmbientCapabilities = "cap_ipc_lock") but I don't think it works for the user-level systemd session. See https://www.freedesktop.org/software/systemd/man/systemd.exec.html#AmbientCapabilities=. If anyone can test the AmbientCapabilities and report back it would be great :)

Alexander-Shukaev commented 3 years ago

I'm on a completely different system but also running into

gnome-keyring-daemon: no process capabilities, insecure memory might get used

as GKD instance is being one of the sub-processes under user-level systemd manager service. Though that's due to me explicitly trying to harden that service with various systemd security options. I can confirm that this happens as soon as NoNewPrivileges=yes. The culprit here is that NoNewPrivileges=yes will be set implicitly if at least one out of many other security options is set, see documentation for the complete list. I can also confirm that AmbientCapabilities=CAP_IPC_LOCK cannot treat this problem because for user-level services, it barks upon service startup:

Failed to apply ambient capabilities (before UID change): Operation not permitted

:cry:

GaetanLepage commented 2 years ago

Hi ! Is there some kind of fix for this problem ?

rycee commented 2 years ago

I'm not sure what the issue is but perhaps adding pkgs.gnome.gnome-keyring to home.packages help?

GaetanLepage commented 2 years ago

It doesn't seem to work. I am now using the NixOS configuration.nix instead to enable gnome keyring. It works like this.

spikespaz commented 1 year ago

Can we get someone in-the-know to take a look at this? Can we copy the functionality of how some desktop environments handle this, but allow it to remain managed as non-root with HM?

ppenguin commented 1 year ago

I'm not sure whether it's the only problem, but for me the HM module of gnome-keyring isn't working, though apparently it starts without issue... The problem is it doesn't set SSH_AUTH_SOCK...

But manual start (in the user xsession) of the keyring daemon has always worked for me:

before: (working)

  xsession = {
    enable = true; # important!
    scriptPath = ".xsession-hm-qtile";
    profileExtra = ''
      export $(${pkgs.gnome.gnome-keyring}/bin/gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh)
    '';
    initExtra = /* this is the equivalent of autostart */ ''
       ...
    '';
    windowManager.command = ''
        export XDG_CURRENT_DESKTOP="qtile"
        ${unstable.qtile}/bin/qtile start -c ${config.xdg.configHome}/qtile/config.py >>"${config.xdg.dataHome}/qtile/qtile.log" 2>&1
    '';
  };

after (doesn't set SSH_AUTH_SOCK) => not working:

Shouldn't the HM module just do the same evaluation like above and export the resulting vars into the xsession?

Semi-related: I was apparently using gpg over keyring as well, why is this not supported by HM while the daemon appears to support it?

SebTM commented 1 year ago

I have the same issue - as I have sway with greetd and gnome-keyring enabled in NixOs-Module and also configured to unlock at login.

Everything regarding secrets works fine:

/nix/store/0w1fpz3ffbl59rh571a00446zni3s31q-gnome-keyring-42.1/bin/gnome-keyring-daemon --daemonize --login

starts auto-magical on login (I suspect pam) taken over by 

/run/wrappers/bin/gnome-keyring-daemon --start --foreground --components=secrets

(also pam?)

Currently I'm spawning these one via the home-manager module:

/run/wrappers/bin/gnome-keyring-daemon --start --foreground --components=pkcs11,ssh

and exporting the SSH_AUTH_SOCK myself in wayland.windowManager.sway.extraSessionCommand

export SSH_AUTH_SOCK=/run/user/$(id -u)/keyring/ssh

which is not ideal if the services gets stopped/dies. It does not finds the way from the systemd-service to the user-environment that's so far what I was able to identify - I also didn't found an easy solution on how to export the env-variable which gets set/echoed on start from the systemd-service?

SebTM commented 1 year ago

Is the systemd-integration https://github.com/nix-community/home-manager/blob/40ebb62101c83de81e5fd7c3cfe5cea2ed21b1ad/modules/services/window-managers/i3-sway/sway.nix#L320 for sway/wayland equal to the xserver-approach here? https://github.com/NixOS/nixpkgs/issues/174099#issuecomment-1201697954

SebTM commented 1 year ago

I also read through here and tried different approaches (copying files, mkDesktopItem to override) even patching out the OnlyShowIn in the gnome-keyring derivation with:

sed -i '/^OnlyShowIn.*$/d' $out/etc/xdg/autostart/*

and using this PR for #3747 for xdg-autostart without success.

novoid commented 10 months ago

FYI: A brand new NixOS setup (setup yesterday from current USB drive; with flakes + HM) does have the very same issue: https://github.com/novoid/nixos-config/tree/09fe61261623c5c88522356bed215825d175ada9 (host "rise")