[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

Debbugs page

M
M
Mark H Weaver wrote on 2 Apr 2021 21: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 2 Apr 2021 21: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 00: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 00: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 04: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 06: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 14: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 10: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 02: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 07: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 14: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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 47576@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47576
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch