Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir
On Mon, 2017-11-27 at 20:30 +0100, Werner Koch wrote:
> On Mon, 27 Nov 2017 18:24, ans...@debian.org said:
>
> > > this is a deliberate choice by upstream.
> >
> > Yes, I saw it in the source :-/
>
> There is a clear reason for this. In the past we had lot of troubles
> with too freely configurable socket names and file systems which
> don't
> support local sockets. Recall that GnuPG 2.x goes back to 2003 and
> it
> has always used the local socket and fully relied on it for gpgsm - a
> maybe nice application but nevertheless a tool which has been in wide
> use since about 2005 by a few large sites. So with 2.2 removed the
> trouble by using a fixed socket dir utilizing the /var/run hierarchy
> which is on all known Unices a local file system supporting sockets.
Was support for /run/user/ around in 2003? I'm fairly sure that
came a bit later.
How many Unices provide /run/user/ and follow the GnuPG semantic
for it? And how many follow XDG semantics for that path?
> The only overhead a _Unix_ sysadm has to do is putting this into
> rc.local:
>
> [ ! -d /run/user ] && mkdir /run/user
> awk -F: = 1000 && $3 < 65000 {print $3}' \
> | ( while read uid rest; do
> if [ ! -d "/run/user/$uid" ]; then
> mkdir /run/user/$uid
> chown $uid /run/user/$uid
> chmod 700 /run/user/$uid
> fi
> done )
That assumes a Real UNIX has rc.local, all user accounts are in
/etc/passwd and only uids in the range [1000, 65000) are used. I'm
fairly sure systems exist where that is not the case. But then maybe
those are no standard Unix systems in the GnuPG sense of standard
and/or Unix ;-)
> Unfortunately Debian GNU/Linux is no longer a standard Unix
> system and thus long standing things don't work anymore. nohup.
> On such semi-Unix systems you need to work around their shortcomings;
> in your case cron. Adding yet another thing and in particular XDG,
> which more targets the desktop than the server, would make things
> more complicate.
Maybe Debian should then try to move away from GnuPG to something that
works better for its core infrastructure instead of having to work
around GnuPG's shortcomings from only supporting "standard Unix
systems" which apparently doesn't include most widely used Linux
distributions these days...
> However, there is another proposal on the gnupg-devel list to try
> another socketdir first. The suggestion is to try the socket names
> in
> this order:
>
> 1. /var/run/gnupg/user/UID/S.gpg-agent
> 2. /var/run/user/UID/gnupg/S.gpg-agent
> 3. HOME/.gnupg/S.gpg-agent
>
> The first one would be new. It has the advantage that systemd does
> not know about it and thus can't remove it (and should not because it
> belongs to gnupg). The disadvantage is that systemd does not remove
> this directory and gpg-agent can't use the directory removal as
> trigger to terminate itself. However, it is at the discretion of the
> sysadm to create such directories in the first place.
Using XDG_RUNTIME_DIR or a GnuPG-specific environment variable would
not require root to configure a different location. The
/run/gnupg/user/ proposal does. If GnuPG will in the future
require root to be configured then be that so.
At least /run/gnupg/user/ doesn't assume different semantics for a
path commonly used differently.
Ansgar
Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir
On Mon, 27 Nov 2017 18:24, ans...@debian.org said:
>> this is a deliberate choice by upstream.
>
> Yes, I saw it in the source :-/
There is a clear reason for this. In the past we had lot of troubles
with too freely configurable socket names and file systems which don't
support local sockets. Recall that GnuPG 2.x goes back to 2003 and it
has always used the local socket and fully relied on it for gpgsm - a
maybe nice application but nevertheless a tool which has been in wide
use since about 2005 by a few large sites. So with 2.2 removed the
trouble by using a fixed socket dir utilizing the /var/run hierarchy
which is on all known Unices a local file system supporting sockets.
The only overhead a _Unix_ sysadm has to do is putting this into
rc.local:
[ ! -d /run/user ] && mkdir /run/user
awk -F: = 1000 && $3 < 65000 {print $3}' \
| ( while read uid rest; do
if [ ! -d "/run/user/$uid" ]; then
mkdir /run/user/$uid
chown $uid /run/user/$uid
chmod 700 /run/user/$uid
fi
done )
Unfortunately Debian GNU/Linux is no longer a standard Unix system and
thus long standing things don't work anymore. nohup.
On such semi-Unix systems you need to work around their shortcomings; in
your case cron. Adding yet another thing and in particular XDG, which
more targets the desktop than the server, would make things more
complicate.
However, there is another proposal on the gnupg-devel list to try
another socketdir first. The suggestion is to try the socket names in
this order:
1. /var/run/gnupg/user/UID/S.gpg-agent
2. /var/run/user/UID/gnupg/S.gpg-agent
3. HOME/.gnupg/S.gpg-agent
The first one would be new. It has the advantage that systemd does not
know about it and thus can't remove it (and should not because it
belongs to gnupg). The disadvantage is that systemd does not remove
this directory and gpg-agent can't use the directory removal as trigger
to terminate itself. However, it is at the discretion of the sysadm to
create such directories in the first place.
The other option would be a global config file to list additional socket
directories to try. That would a require a bit more code but that shall
not be the problem.
> Yes, but that depends on the internal gpg logic to decide where to put
> sockets (which is unstable). If one could tell gpg which directory to
That is not unstable due to gpg but because something removes or creates
directories which are supposed to exist right after system startup or at
least before calling gpg the first time.
> It also requires to call gpgconf to configure the supervisor (and the
> location might change at any time in the future so gpgconf needs to be
The directories are fixed and won't change: Iff /var/run/user/UID exists
it is used, if not ~/.gnupg is used (with all its problems).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpiqhccJmTEI.pgp
Description: PGP signature
Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir
On Mon, 2017-11-27 at 10:02 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2017-11-26 12:00:31 +0100, Ansgar Burchardt wrote:
> > gpg(-agent) uses a different socketdir when a non-default homedir
> > is
> > specified depending on the environment:
> >
> > If /run/user/ exists, it will use
> > /run/user//gnupg/d.;
> > otherwise it will fall back to . XDG_RUNTIME_DIR is
> > intentionally ignored...
>
> this is a deliberate choice by upstream.
Yes, I saw it in the source :-/
> > This does cause multiple instances of gpg-agent to be launched when
> > first invoking `gpg` with no open login session (/run/user/
> > does
> > not exist) and then again with an open login session open (which
> > created /run/user/).
>
> how are you launching gpg without a login session? that's not a
> common workflow from what i can tell.
>From a script invoked from cron. That doesn't open a logind session.
sudo would work too.
> > In addition it would be nice if there was an option to explicitly
> > configure a socket directory to allow using supervision for
> > gpg-agent's with a non-default homedir (and not having to rely on
> > implementation details like d.${hash} which might change).
>
> I don't understand what you're asking for here.
>
> The socket path used by the clients of the agent should be stable if
> you
> discover the agent's socket path like so:
>
>gpgconf --homedir=/wherever --list-dirs agent-socket
>
> So you should be able to supervise that location, right?
Yes, but that depends on the internal gpg logic to decide where to put
sockets (which is unstable). If one could tell gpg which directory to
use, one could work around gpg choosing something unstable.
It also requires to call gpgconf to configure the supervisor (and the
location might change at any time in the future so gpgconf needs to be
called always).
(For now I wrked around the problem by having a lingering systemd-
logind session for the service user. Then /run/user/ always
exists.)
Ansgar
Bug#882736: [pkg-gnupg-maint] Bug#882736: gpg-agent: does not always use same socketdir
On Sun 2017-11-26 12:00:31 +0100, Ansgar Burchardt wrote:
> gpg(-agent) uses a different socketdir when a non-default homedir is
> specified depending on the environment:
>
> If /run/user/ exists, it will use /run/user//gnupg/d.;
> otherwise it will fall back to . XDG_RUNTIME_DIR is
> intentionally ignored...
this is a deliberate choice by upstream.
> This does cause multiple instances of gpg-agent to be launched when
> first invoking `gpg` with no open login session (/run/user/ does
> not exist) and then again with an open login session open (which
> created /run/user/).
how are you launching gpg without a login session? that's not a common
workflow from what i can tell.
> Only one gpg-agent will be able to access smartcards, the other will
> just give an error.
yes, smartcard access is limited to one running scdaemon per machine.
> If both `gpg` invocations happened outside a login session, usually
> XDG_RUNTIME_DIR wouldn't be set and gpg would always use the same
> socket location (unless also invoked from within a session with
> XDG_RUNTIME_DIR set). Or one could set XDG_RUNTIME_DIR to a fixed
> location before invoking gpg (or unset it), but gpg ignores that
> variable.
If you're concerned about XDG_RUNTIME_DIR, you should try to re-open
discussion with upstream about it:
https://dev.gnupg.org/T1330
If upstream can't be convinced, and you've got a patch that you think
debian should carry to be more distro-compatible, feel free to propose
it on this bug report.
> In addition it would be nice if there was an option to explicitly
> configure a socket directory to allow using supervision for
> gpg-agent's with a non-default homedir (and not having to rely on
> implementation details like d.${hash} which might change).
I don't understand what you're asking for here.
The socket path used by the clients of the agent should be stable if you
discover the agent's socket path like so:
gpgconf --homedir=/wherever --list-dirs agent-socket
So you should be able to supervise that location, right?
or are you looking for something else?
--dkg
