Daniel Kahn Gillmor wrote: > On Sun 2018-01-07 23:23:16 +1100, gn...@raf.org wrote: > > For the actual decryption, I'm using sudo. From the original > > post, the command to set things up contains something like: > > > > /usr/bin/screen -- \ > > /usr/bin/sudo -u thing --set-home -- \ > > /usr/bin/gpg-agent --homedir /etc/thing/.gnupg \ > > --allow-preset-passphrase \ > > --default-cache-ttl 3600 \ > > --max-cache-ttl 3600 \ > > --daemon $gpg_agent_info -- \ > > /bin/bash --login > > this is deliberately launching a second agent, outside of the basic > supervision that should already be in place.
No. It's starting the *first* agent. Remember, I had disabled systemd's handling of gpg-agent so there is no supervising gpg-agent process started by systemd. When I showed the two gpg-agent processes that existed after the incoming ssh connection ran gpg, they were the only two gpg-agent processes owned by the 'thing' user. There was no supervising one or I would have shown that one as well. The problem is that the subsequent incoming ssh connection runs gpg and that gpg process starts a second gpg-agent process (which has no knowledge of the passphrase) rather than connecting to this first gpg-agent process (which does have knowledge of the passphrase - at least it does until the new gpg-agent is started possibly because it took over the sockets that were created by the first gpg-agent process). > If you want to use the standard system agent, please do not launch a > separate agent. As I stated some time ago, I don't want to use the "standard system agent" because I don't trust systemd to know when it's ok to remove resources. I have had too much trouble caused by systemd concluding that it was time to remove crucial resources to be able trust it with anything that I need to rely on. > This should be as simple as: > > screen -- sudo -u thing --login > > or, if you're doing this as root already, then you don't need sudo at > all, and it could just be: > > screen -- su - testuser It's not run as root. > If this is run from cron, it will spawn a new session, and that session > will have a systemd session manager capable of spawning gpg-agent as > needed. It's not run from cron. It wouldn't make sense to run it from cron. > unfortunately, it will not spawn a new session if run from an existing > session, see the discussion at > https://github.com/systemd/systemd/issues/7451 . > > if you want to manually start a new session for a new user from within > an existing session on a machine managed by systemd, apparently > machinectl may be the way to go, but i haven't explored that in full. That must explain why systemd didn't create a /var/run subdirectory for the 'thing' user during the sudo process (when I re-enabled systemd's handling of gpg-agent). But machinectl seems to be for containers. I'd rather not go there since it might not be right since I'm not using containers. It seems like a hack. I think this is just another argument/example to support my preference for avoiding the additional complexity of systemd here and just using gnupg by itself. > hope this helps, > > --dkg Thanks. I appreciate the effort and research but it doesn't really help. It doesn't address the issue of the incoming ssh connection's gpg process starting up a new gpg-agent process rather than connecting to the existing one. But don't worry. I'm sure I've wasted enough of your time. When I get time, I'll debug what's happening and either realise what needs to be done or work around it somehow. Thanks, raf _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
