Summary: | app-crypt/gnupg ipc socket handling violates sandbox | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alon Bar-Lev (RETIRED) <alonbl> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | alonbl, base-system, floppym, polynomial-c |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=623622 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alon Bar-Lev (RETIRED)
2017-07-08 23:50:07 UTC
(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. |