Continue discussion from bug#623622. gnupg modified their ipc socket location to /run unconditionally. This has several side effects: 1. Support $HOME is a filesystem that does not support usock. 2. Inability to use multiple daemon environment, in the past GNUPGHOME environment could have been set to enable multi-instance of a configuration. How can unit tests of packages such as gpgme interact with their own daemons without killing/modifying state of user specific daemons. This is not related directly to Gentoo, but in our case tests violates sandbox check. A solution in which the location of the ipc socket can be specified via environment would be nice, this can be used also in upstream tests to avoid leakage outside of build directory.
(In reply to Alon Bar-Lev from comment #0) > Continue discussion from bug#623622. > Thanks for opening own bug for this > gnupg modified their ipc socket location to /run unconditionally. > Well, it isn't entirely unconditionally, it presumes /run/user/$UID or /var/run/user/$UID existing > > 2. Inability to use multiple daemon environment, in the past GNUPGHOME > environment could have been set to enable multi-instance of a configuration. I'm not sure if this is true, different GNUPGHOME / --homedir specification will be created in subdir of /run/user/$UID/gnupg/ so they are independent of eachother for purposes of gpgconf etc > > How can unit tests of packages such as gpgme interact with their own daemons > without killing/modifying state of user specific daemons. See above > > This is not related directly to Gentoo, but in our case tests violates > sandbox check. Right, this is an issue. > > A solution in which the location of the ipc socket can be specified via > environment would be nice, this can be used also in upstream tests to avoid > leakage outside of build directory. Indeed, for others reading this a proof of concept exists in bug 623622.
Regarding sandbox: is there some reason you cannot "addwrite /run/$UID/gnupg" in src_test?
(In reply to Mike Gilbert from comment #2) > Regarding sandbox: is there some reason you cannot "addwrite > /run/$UID/gnupg" in src_test? Thats what I'm trying to figure out, but so far I'm with sandbox exception.
I suppose /run/user/250 is unlikely to exist; it generally gets created by something like systemd-logind.
(In reply to Mike Gilbert from comment #4) > I suppose /run/user/250 is unlikely to exist; it generally gets created by > something like systemd-logind. Well, gnupg is a bit systemd happy (well, at least with dkg's help=, so it is also created by gpgconf --create-socketdir, which became a default thing in 2.1.20 (c.f bug 623622 bug 14)
(In reply to Kristian Fiskerstrand from comment #5) > (In reply to Mike Gilbert from comment #4) > > I suppose /run/user/250 is unlikely to exist; it generally gets created by > > something like systemd-logind. > > Well, gnupg is a bit systemd happy (well, at least with dkg's help=, so it > is also created by gpgconf --create-socketdir, which became a default thing > in 2.1.20 (c.f bug 623622 bug 14) bug 623622 comment 14
You must be root to write to /run/user/; the default portage user (uid 250) would be unable to create /run/user/$UID/ without some external (suid) helper, or a real login/pam session.
(In reply to Mike Gilbert from comment #7) > You must be root to write to /run/user/; the default portage user (uid 250) > would be unable to create /run/user/$UID/ without some external (suid) > helper, or a real login/pam session. if /run/user/$UID/ or /var/run/user/$UID doesn't exist, gnupg defaults to $GNUPGHOME, so the sandbox violation only occurs when it actually exists, whereby gnupg dir (and if non-default homedir, a subdirectory) gets created.
