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
