GNUPGHOME is ignored

[gtmanfred]

For some reason GNUPGHOME is ignored when using envoy. If I just use source <(gpg-agent --daemon --enable-ssh-support) it works fine.

[vodik]

K, settinging Environment=GNUPGHOME=... in the .service file should now work.

[pablox-cl]

I ran into this. I'm running envoy as root (systemctl start envoy@gpg-agent.sockett). I rather not run it trough my own user, but I'm seeing it generates a new .gnupg directory when called. How can I solve this without having to mess with upstream files?

[gtmanfred]

drop it into /etc/systemd/system/envoy@gpg-agent.service.d/home.conf

[Service]
Environment=GNUPGHOME=/path/to/home

Then it will use everything from the regular service file in /usr/lib/systemd, but add this environment variable.

[pablox-cl]

Hm, I guess I can do that, but I was thinking in something more portable or totally independent from root. It's a good workaround though, I'll give it a try.

[gtmanfred]

You can't really seperate it for a systemd unit, because you have to have it be in the environment where the unit runs. If you use systemd-user sessions, you could use the user version of the envoy unit

https://wiki.archlinux.org/index.php/Systemd/User

I modify mine in ~/.config/systemd/user/envoy@gpg-agent.service.d/home.conf

┌─ daniel at hailey in ~
└─╼ pacman -Ql envoy-git | grep user (⌐■_■)
envoy-git /usr/lib/systemd/user/
envoy-git /usr/lib/systemd/user/envoy@.service
envoy-git /usr/lib/systemd/user/envoy@.socket

But if you want it enabled for all users, that would be system wide, so you have to set it up using the system administrator... root.

You actually might be able to set /etc/systemd/user/envoy@gpg-agent.service.d/home.conf, but that would still require it to be set by the root user, but would apply to each users systemd user session

[vodik]

@pablox-cl there is no reason it couldn't be passed from envoy to envoyd. I'll give this a go when I got some free time over the holidays.

[vodik]

@pablox-cl Actually, now that I've looked into this more closely, its a lot more complicated and there is no other way to do this robustly. The problem when using envoy you really shouldn't assume that any particualar invocation of the command will actually be the one that forks off the gpg-agent process. The pam module or some other script run earlier may have already started the agent. What do we do then? And what do we do in the case where gpg-agent was initially started with one GNUPGHOME but now we're asking for a different one?

The only robust way is to define it envoyd's environment and let it propegate to gpg-agent.

more portable or totally independent from root.

As its implemented, GNUPGHOME will only propegate if we run everything as a user (hence the user session support, please file a bug if it doesn't work for you). If we run envoyd root it will ignore that variable (and log a message saying its doing so). And I do a security check so one user can't ask for another user's agent.

[pablox-cl]

No, it's okay. I undestand. I just think using systemd --user is still too experimental. I'll use the workaround stated above :)

[vodik]

@pablox-cl I've just ported envoy to use the new sd-bus API, user sessions should be supported now, if you still care:

$ systemctl status --user envoy-gpg-agent-monitor-1000.scope 
● envoy-gpg-agent-monitor-1000.scope - Envoy agent monitoring scope
   Loaded: loaded (/home/simon/.config/systemd/user/envoy-gpg-agent-monitor-1000.scope; static)
  Drop-In: /home/simon/etc/systemd/user/envoy-gpg-agent-monitor-1000.scope.d
           └─90-Description.conf, 90-Slice.conf
   Active: active (running) since Sun 2015-06-28 15:41:53 EDT; 4min 36s ago
   CGroup: /user.slice/user-1000.slice/user@1000.service/envoy.slice/envoy-gpg-agent-monitor-1000.scope
           └─2305 /usr/bin/gpg-agent --daemon --enable-ssh-support

Jun 28 15:41:53 nesasio systemd[352]: Started Envoy agent monitoring scope.

[vodik]

Okay, still some issues, follow #47 for this.