[security] ibus-daemon launches ungrafted subprocesses

  • Open
  • quality assurance status badge
Details
6 participants
  • Julien Lepiller
  • Léo Le Bouter
  • Ludovic Courtès
  • Maxime Devos
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Mark H Weaver
Severity
normal
M
M
Mark H Weaver wrote on 3 Apr 2021 06:44
(address . bug-guix@gnu.org)
87pmzcdljm.fsf@netris.org
Several processes on my Guix system load shared libraries from the
*ungrafted* glib: specifically, all of the subprocesses of
'ibus-daemon'.

The 'ibus-daemon' process itself seems to be properly grafted. However,
its subprocesses are from an old, ungrafted build of 'ibus':

Toggle snippet (18 lines)
mhw@jojen ~$ pstree -up 796
.ibus-daemon-re(796,mhw)???.ibus-dconf-rea(803)???{.ibus-dconf-rea}(806)
? ??{.ibus-dconf-rea}(807)
??.ibus-engine-si(892)???{.ibus-engine-si}(917)
? ??{.ibus-engine-si}(918)
??.ibus-extension(804)???{.ibus-extension}(810)
? ??{.ibus-extension}(811)
? ??{.ibus-extension}(819)
??{.ibus-daemon-re}(797)
??{.ibus-daemon-re}(798)
mhw@jojen ~$ ps -fq 796,803,892,804
UID PID PPID C STIME TTY TIME CMD
mhw 796 698 0 00:10 tty8 00:00:00 /gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22/bin/ibus-daemon --panel disable -r --xim
mhw 803 796 0 00:10 tty8 00:00:00 /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-dconf
mhw 892 796 0 00:10 tty8 00:00:00 /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-engine-simple
mhw 804 796 2 00:10 tty8 00:00:01 /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-extension-gtk3

(The same issue occurs for the 'ibus-daemon' that's owned by 'gdm').

/gnu/store/radg…-ibus-1.5.22 seems to be the properly grafted 'ibus',
replacing the ungrafted /gnu/store/wnqv…-ibus-1.5.22 which I last built
on February 2nd: (I don't use substitutes)

Toggle snippet (6 lines)
mhw@jojen ~$ bzcat $(guix build --log-file /gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22)
grafting '/gnu/store/wnqv8rj3ngjivl6334d1h8irszf39dm9-ibus-1.5.22' -> '/gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22'...
mhw@jojen ~$ ls -l $(guix build --log-file /gnu/store/wnqv8rj3ngjivl6334d1h8irszf39dm9-ibus-1.5.22)
-rw-r--r-- 1 root root 24923 Feb 2 10:35 /var/log/guix/drvs/hx/qpdblmghj7pvg0ni2l38p0a1s4igbd-ibus-1.5.22.drv.bz2

The reference scanner does not see any references to any other 'ibus',
from either my system, my user profile, or the grafted 'ibus':

Toggle snippet (7 lines)
mhw@jojen ~$ guix gc -R $(readlink -f /run/current-system) | grep -e -ibus-
/gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22
mhw@jojen ~$ guix gc -R $(readlink -f ~/.guix-profile) | grep -e -ibus-
mhw@jojen ~$ guix gc -R /gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22 | grep -e -ibus-
/gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22

Interestingly, the subprocesses are *not* from the ungrafted 'ibus' that
I last built on February 2nd. Instead, they are from a much older
ungrafted 'ibus', which I last built on December 20th of last year:

Toggle snippet (4 lines)
mhw@jojen ~$ ls -l $(guix build --log-file /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22)
-rw-r--r-- 1 root root 24981 Dec 20 20:33 /var/log/guix/drvs/sn/k6581cpk6n8q3dvsarqmqimhx0n2i2-ibus-1.5.22.drv.bz2

I'm at a bit of a loss of where this much older, ungrafted 'ibus' is
coming from. Running "guix build ibus", with and without grafts, give
the other two 'ibus' store items:

Toggle snippet (6 lines)
mhw@jojen ~$ guix build ibus --no-grafts
/gnu/store/wnqv8rj3ngjivl6334d1h8irszf39dm9-ibus-1.5.22
mhw@jojen ~$ guix build ibus
/gnu/store/radg6xacqvw60d76k97y0ydccjm7iq7a-ibus-1.5.22

Is there another variant of the 'ibus' package hiding somewhere?
Where is "/gnu/store/a4r6…-ibus-1.5.22" coming from?

I don't know that I'll have the energy to investigate this further
anytime soon, so I'm hoping that someone else will pick this up.

* * *

FYI, I discovered this while doing sanity checks on my new preliminary
grafting implementation (which supports rewriting UTF-16/32 store
references). Looking for references to the old 'glib' was the *first*
thing I checked. I haven't yet checked anything else, so I don't know
how widespread this problem is.

Mark
M
M
Mark H Weaver wrote on 3 Apr 2021 06:51
(address . 47576@debbugs.gnu.org)
87mtugdl74.fsf@netris.org
Here's an obvious check that I should have included in my last message:

Toggle snippet (5 lines)
mhw@jojen ~$ guix gc --referrers /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22
/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22
mhw@jojen ~$

This is the 'ibus' that I last built in December 2020, and which is
somehow, mysteriously, being used for the subprocesses of 'ibus-daemon'.

Mark
M
M
Mark H Weaver wrote on 3 Apr 2021 09:12
(address . 47576@debbugs.gnu.org)
877dljdenq.fsf@netris.org
Earlier, I wrote:
Toggle quote (4 lines)
> Looking for references to the old 'glib' was the *first* thing I
> checked. I haven't yet checked anything else, so I don't know how
> widespread this problem is.

I looked for other ungrafted libraries loaded on my system, and I'm glad
to report that I see no evidence of any grafting problem other than this
'ibus-daemon' issue.

The following ungrafted libraries are loaded by processes from the
mysterious old version of 'ibus' on my system: glib, cairo, and libx11.
I still have no clue where the reference to that mysterious old version
(/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming
from.

Are other people seeing this? Here's an easy way to check:

Toggle snippet (13 lines)
mhw@jojen ~$ ps axf | grep -e -ibus-
402 tty7 Sl 0:00 | | \_ /gnu/store/vdc4j6c9psx8jicr5h2n8jdxsfjms3h2-ibus-1.5.22/bin/ibus-daemon --panel disable -r --xim
407 tty7 Sl 0:00 | | \_ /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-dconf
450 tty7 Sl 0:00 | | \_ /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-engine-simple
798 tty8 Sl 0:00 | \_ /gnu/store/vdc4j6c9psx8jicr5h2n8jdxsfjms3h2-ibus-1.5.22/bin/ibus-daemon --panel disable -r --xim
804 tty8 Sl 0:00 | | \_ /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-dconf
805 tty8 Sl 0:01 | | \_ /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-extension-gtk3
894 tty8 Sl 0:00 | | \_ /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22/libexec/ibus-engine-simple
2246 pts/0 S+ 0:00 | | | \_ grep -e -ibus-
409 tty7 Sl 0:00 /gnu/store/vdc4j6c9psx8jicr5h2n8jdxsfjms3h2-ibus-1.5.22/libexec/ibus-x11 --kill-daemon
808 tty8 Sl 0:00 /gnu/store/vdc4j6c9psx8jicr5h2n8jdxsfjms3h2-ibus-1.5.22/libexec/ibus-x11 --kill-daemon

If you run this command, do you also see different 'ibus' store items
used by the daemon and its subprocesses?

Mark
M
M
Mark H Weaver wrote on 3 Apr 2021 09:31
(address . 47576@debbugs.gnu.org)
874kgndds4.fsf@netris.org
I wrote:
Toggle quote (4 lines)
> I still have no clue where the reference to that mysterious old version
> (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming
> from.

I found them:

~/.cache/ibus/bus/registry
/var/lib/gdm/.cache/ibus/bus/registry

On my system, those files include absolute pathnames to programs in
/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22, which I
compiled last December.

That old store item has been kept safe from GC for only one reason:
because 'ibus-daemon', along with its subprocesses, tend to be running
whenever I run "guix gc", and "guix gc" protects store items that are
currently in use by active processes.

Mark
J
J
Julien Lepiller wrote on 3 Apr 2021 13:29
8BEEF3C6-82DC-459A-9013-3850754DA3B2@lepiller.eu
Oh! That would explain why I had so much trouble fixing/updating ibus and ibus-anthy!

We should probably fix ibus so it regenerates its cache when it's a different process. It could be as simple as using a subdirectory computed from the absolute name of the ibus binary, maybe.

Le 3 avril 2021 03:31:44 GMT-04:00, Mark H Weaver <mhw@netris.org> a écrit :
Toggle quote (21 lines)
>I wrote:
>> I still have no clue where the reference to that mysterious old
>version
>> (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming
>> from.
>
>I found them:
>
> ~/.cache/ibus/bus/registry
> /var/lib/gdm/.cache/ibus/bus/registry
>
>On my system, those files include absolute pathnames to programs in
>/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22, which I
>compiled last December.
>
>That old store item has been kept safe from GC for only one reason:
>because 'ibus-daemon', along with its subprocesses, tend to be running
>whenever I run "guix gc", and "guix gc" protects store items that are
>currently in use by active processes.
>
> Mark
Attachment: file
M
M
Maxime Devos wrote on 3 Apr 2021 15:16
6df8bcf53b5f73402ae375f3772a9675c94250ae.camel@telenet.be
On Sat, 2021-04-03 at 03:12 -0400, Mark H Weaver wrote:
Toggle quote (15 lines)
> [...]
>
> The following ungrafted libraries are loaded by processes from the
> mysterious old version of 'ibus' on my system: glib, cairo, and libx11.
> I still have no clue where the reference to that mysterious old version
> (/gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22) is coming
> from.
>
> Are other people seeing this? Here's an easy way to check:
>
> [...]
>
> If you run this command, do you also see different 'ibus' store items
> used by the daemon and its subprocesses?

I also see different store items:

$ ps axf | grep -e -ibus-
Toggle quote (1 lines)
> 1141 tty7 Sl 0:00 | | \_ /gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/bin/ibus-daemon --panel disable -r
--xim
Toggle quote (5 lines)
> 1146 tty7 Sl 0:00 | | \_ /gnu/store/7m04iv3pks6m6p8czw1mj58194rnfjyy-ibus-1.5.22/libexec/ibus-dconf
> 1269 tty7 Sl 0:00 | | \_ /gnu/store/7m04iv3pks6m6p8czw1mj58194rnfjyy-ibus-1.5.22/libexec/ibus-engine-simple
> 1148 tty7 Sl 0:00 /gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-x11 --kill-daemon
> 25649 pts/5 S+ 0:00 \_ grep --color=auto -e -ibus-

FWIW, this is on MATE. (TODO to self: investigate why GNOME Shell crashes
after a few seconds.)

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYIADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYGhqwRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7hXcAQCZs3+PKOz2+gSPP5pouzNaF1UE
TWZPD7HOqC8oxYK0RgD+NYCc29LL/mfqx4AuUc8yTga50SdJvdCpXx+Qt1wR4Aw=
=r2jI
-----END PGP SIGNATURE-----


M
M
Mark H Weaver wrote on 3 Apr 2021 23:10
87zgyf845d.fsf@netris.org
Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:
Toggle quote (4 lines)
> We should probably fix ibus so it regenerates its cache when it's a
> different process. It could be as simple as using a subdirectory
> computed from the absolute name of the ibus binary, maybe.

Would you like to try?

I won't be able to work more on this bug anytime soon, but I hope that
others will pick it up.

Thanks,
Mark
L
L
Léo Le Bouter wrote on 6 Apr 2021 19:41
(address . control@debbugs.gnu.org)
cdf381c2117ff90daa8756e6cf3c6632f2479c34.camel@zaclys.net
tags 47576 + security
quit
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBsnToACgkQRaix6GvN
EKaCUxAAtRzdj5gvINukhhl8JelDs+fM09+yztIyq4G07E/CiME3JcxFlNKJem2T
Ex5/H9QzZ8npOGBFXNH2H3YPAkBAvgrkdJyKqVmaBVyniEm6+ACkdVBcxYGvGlGF
f8Sw3tuNjLZ35A9HQpbU/njjIwE09ny4f5Uzlsv5Wf4psypOXCx/277Alfuf+3sK
NHCMTGbVPqSxxKGviKGa22wKeCyfdPu9NjXA+5sfuW0PE7vSEGalVtkPS3Cf3FPx
p7l1JgfPp5Sh50HOqEKBFM74nqdyr1Oj3lO5D9V2/ZKXoUC7EdI5JreEHRWNR8c+
wg004i2F5Xt3voIZf8BXLWqa9yaWC3VxZKoQLctr680Hv+6ZD2qD7BvfJnckRlef
r4bgzkChT86ASd1X6kfl9XWCCEyUOnTKXVwxfA/+ZHW5aNrdri4QXzaJ6CQM1vB0
FIO5Ci0SPeBJoAgXoza6/GbZ0xyI7a40+LbV0zV1PK273+2X+XQptagqOrLlQ8TH
QLBelX3unarBN0C9cJoVBsqj3gddloqSNCKJPQiDDt5+0opCZH9hvMKuTAaowitm
FuKQZTNo3nRREacYggmBzU82UDjOmsZ4sCbh2UWvNGN+Fns/Bihg67RVFsxUrKvk
w9PoJD67b6a+S/XBWip8U8ivPnH7HVTheSWBAbcCx66IFBzfMBY=
=tbOx
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 9 Apr 2021 11:06
(name . Mark H Weaver)(address . mhw@netris.org)(address . 47576@debbugs.gnu.org)
87pmz37rol.fsf@gnu.org
Hi,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (9 lines)
> I found them:
>
> ~/.cache/ibus/bus/registry
> /var/lib/gdm/.cache/ibus/bus/registry
>
> On my system, those files include absolute pathnames to programs in
> /gnu/store/a4r6q1fbfqapy5hrrxap1yg96rjgln6q-ibus-1.5.22, which I
> compiled last December.


The problem seems to generally affect GLib/GNOME-ish caches.

From a quick look at ibusregistry.c & co, I think the values that end up
in the cache are taken from these XML files:

Toggle snippet (7 lines)
$ grep /gnu/store $(find $(guix build ibus) -name \*.xml)
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/gtkpanel.xml: <exec>/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-ui-gtk3</exec>
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/dconf.xml: <exec>/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-dconf</exec>
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/simple.xml: <exec>/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-engine-simple</exec>
/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/share/ibus/component/gtkextension.xml: <exec>/gnu/store/a7lxf1i35yqil6pxwxhzvr5q3xcqldyq-ibus-1.5.22/libexec/ibus-extension-gtk3</exec>

It’s the ‘components’ field of _IBusRegistryPrivate:

Toggle snippet (17 lines)
struct _IBusRegistryPrivate {
/* a list of IBusObservedPath objects. */
GList *observed_paths;

/* a list of IBusComponent objects that are created from component XML
* files (or from the cache of them). */
GList *components;

gboolean changed;

/* a mapping from GFile to GFileMonitor. */
GHashTable *monitor_table;

guint monitor_timeout_id;
};

The attached patch does the following:

1. change the above <exec> file names in XML files to relative file
names;

2. change ibuscomponent.c to automatically prepend $libexecdir to
<exec> items that are relative file names.

That way, XML files and thus caches should only contain relative file
names for ibus’ own executables.

The attached patch builds with:

guix build ibus --with-patch=ibus=/tmp/ibus.patch

… but I don’t know if it actually works. Testing welcome. :-)

Unfortunately this strategy doesn’t help with IBus extensions:

Toggle snippet (5 lines)
$ grep exec $(find $(guix build ibus-anthy) -name \*.xml)
/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/share/ibus/component/anthy.xml: <exec>/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/libexec/ibus-engine-anthy --ibus</exec>
/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/share/ibus/component/anthy.xml: <engines exec="/gnu/store/d3mfffz41as1blfb28m8n461j42i6zjr-ibus-anthy-1.5.9/libexec/ibus-engine-anthy --xml" />

Thoughts?

Ludo’.
Toggle diff (112 lines)
diff --git a/conf/dconf/dconf.xml.in b/conf/dconf/dconf.xml.in
index 4205cb0..538f500 100644
--- a/conf/dconf/dconf.xml.in
+++ b/conf/dconf/dconf.xml.in
@@ -3,7 +3,7 @@
<component>
<name>org.freedesktop.IBus.Config</name>
<description>Dconf Config Component</description>
- <exec>@libexecdir@/ibus-dconf</exec>
+ <exec>ibus-dconf</exec>
<version>@VERSION@</version>
<author>Daiki Ueno &lt;ueno@unixuser.org&gt;</author>
<license>GPL</license>
diff --git a/conf/memconf/memconf.xml.in b/conf/memconf/memconf.xml.in
index d6ea690..9f51bcc 100644
--- a/conf/memconf/memconf.xml.in
+++ b/conf/memconf/memconf.xml.in
@@ -2,7 +2,7 @@
<component>
<name>org.freedesktop.IBus.Config</name>
<description>On-memory Config Component</description>
- <exec>@libexecdir@/ibus-memconf</exec>
+ <exec>ibus-memconf</exec>
<version>@VERSION@</version>
<author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;, modified by the Chromium OS Authors</author>
<license>GPL</license>
diff --git a/engine/simple.xml.in b/engine/simple.xml.in
index fc1541e..47cbea1 100644
--- a/engine/simple.xml.in
+++ b/engine/simple.xml.in
@@ -2,7 +2,7 @@
<component>
<name>org.freedesktop.IBus.Simple</name>
<description>A table based simple engine</description>
- <exec>@libexecdir@/ibus-engine-simple</exec>
+ <exec>ibus-engine-simple</exec>
<version>@VERSION@</version>
<author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
<license>GPL</license>
diff --git a/src/Makefile.am b/src/Makefile.am
index a8e3d07..2c461ee 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -49,6 +49,7 @@ AM_CPPFLAGS = \
@GLIB2_CFLAGS@ \
@GOBJECT2_CFLAGS@ \
@GIO2_CFLAGS@ \
+ -DLIBEXECDIR=\"$(libexecdir)\" \
-DIBUS_CACHE_DIR=\""$(localstatedir)/cache/ibus"\" \
-DIBUS_DATA_DIR=\"$(pkgdatadir)\" \
-DIBUS_DISABLE_DEPRECATION_WARNINGS \
diff --git a/src/Makefile.in b/src/Makefile.in
index 2a9c2ab..c3dfd87 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -613,6 +613,7 @@ CLEANFILES = $(am__append_2) $(BUILT_SOURCES) stamp-ibusmarshalers.h \
# C preprocessor flags
AM_CPPFLAGS = -DG_LOG_DOMAIN=\"IBUS\" @GLIB2_CFLAGS@ @GOBJECT2_CFLAGS@ \
@GIO2_CFLAGS@ \
+ -DLIBEXECDIR=\"$(libexecdir)\" \
-DIBUS_CACHE_DIR=\""$(localstatedir)/cache/ibus"\" \
-DIBUS_DATA_DIR=\"$(pkgdatadir)\" \
-DIBUS_DISABLE_DEPRECATION_WARNINGS -DIBUS_COMPILATION \
diff --git a/src/ibuscomponent.c b/src/ibuscomponent.c
index 9837f47..4b55a66 100644
--- a/src/ibuscomponent.c
+++ b/src/ibuscomponent.c
@@ -614,6 +614,18 @@ ibus_component_parse_engines (IBusComponent *component,
if (exec != NULL) {
gchar *output = NULL;
+
+ if (exec[0] != '/') {
+ /* EXEC is a relative file name, so assume it's the name of an
+ executable in $libexecdir and expand it. */
+ GString *absolute = g_string_new (LIBEXECDIR);
+ g_string_append (absolute, "/");
+ g_string_append (absolute, exec);
+
+ g_free (exec);
+ exec = g_string_free (absolute, FALSE);
+ }
+
if (g_spawn_command_line_sync (exec, &output, NULL, NULL, NULL)) {
engines_node = ibus_xml_parse_buffer (output);
g_free (output);
diff --git a/ui/gtk3/gtkextension.xml.in b/ui/gtk3/gtkextension.xml.in
index b8157c9..fc945ab 100644
--- a/ui/gtk3/gtkextension.xml.in
+++ b/ui/gtk3/gtkextension.xml.in
@@ -3,7 +3,7 @@
<component>
<name>org.freedesktop.IBus.Panel.Extension</name>
<description>Gtk Panel Extension Component</description>
- <exec>@libexecdir@/ibus-extension-gtk3</exec>
+ <exec>ibus-extension-gtk3</exec>
<version>@VERSION@</version>
<author>Takao Fujiwara &lt;takao.fujiwara1@gmail.com&gt;</author>
<license>GPL</license>
diff --git a/ui/gtk3/gtkpanel.xml.in b/ui/gtk3/gtkpanel.xml.in
index b61f400..2175b93 100644
--- a/ui/gtk3/gtkpanel.xml.in
+++ b/ui/gtk3/gtkpanel.xml.in
@@ -3,7 +3,7 @@
<component>
<name>org.freedesktop.IBus.Panel</name>
<description>Gtk Panel Component</description>
- <exec>@libexecdir@/ibus-ui-gtk3</exec>
+ <exec>ibus-ui-gtk3</exec>
<version>@VERSION@</version>
<author>Peng Huang &lt;shawn.p.huang@gmail.com&gt;</author>
<license>GPL</license>
R
R
Ricardo Wurmus wrote on 20 Apr 2021 16:51
[security] ibus-daemon launches ungrafted subprocesses
(address . 47576@debbugs.gnu.org)
87v98hko0z.fsf@elephly.net
merge 47576 22707
thanks

Ludo, the patch looks good to me. However, many ibus input
methods are not provided by the ibus package itself, so for
ibus-anthy or ibus-libpinyin we would need a different mechanism.

Would it make sense to introduce another environment variable
(e.g. GUIX_IBUS_COMPONENTS_PATH) that specifies a search path on
which components are looked up? I feel that this partially
defeats the purpose of having a cache, so perhaps this is
nonsensical.

What do you think?

--
Ricardo
L
L
Ludovic Courtès wrote on 20 Apr 2021 23:26
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 47576@debbugs.gnu.org)
8735vkabrd.fsf@gnu.org
Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (4 lines)
> Ludo, the patch looks good to me. However, many ibus input methods
> are not provided by the ibus package itself, so for ibus-anthy or
> ibus-libpinyin we would need a different mechanism.

Right.

Toggle quote (5 lines)
> Would it make sense to introduce another environment variable
> (e.g. GUIX_IBUS_COMPONENTS_PATH) that specifies a search path on
> which components are looked up? I feel that this partially defeats
> the purpose of having a cache, so perhaps this is nonsensical.

That makes sense to me.

Attached is a variant of the previous patch that supports
GUIX_IBUS_COMPONENTS_DIRECTORY (not PATH because… it’s complicated).
It would be set to $HOME/.guix-profile/libexec.

We then need to modify the XML files of ibus-anthy, ibus-libpinyin,
etc. so that their <exec> tags use relative file names.

Thoughts?

Ludo’.

PS: IBus still builds with the patch, but that’s all I can say. :-)
Attachment: ibus.patch
?