Ubuntu
ibus package

ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus

Bug #1761585 reported by Olivier Tilloy on 2018-04-05

This bug affects 1 person

	Status	Importance	Assigned to
ibus	Fix Released	Unknown	auto-github-ibus-ibus #1996
ibus (Ubuntu)	Fix Released	Low	Olivier Tilloy
Xenial	Fix Released	Undecided	Unassigned

Bug Description

This was spotted by jdstrand when running the chromium snap, which recently enabled ibus support (https://forum.snapcraft.io/t/cant-use-input-method-in-snap-apps/4712/12):

audit[16919]: AVC apparmor="DENIED" operation="chmod" profile="snap.chromium.chromium" name="/home/osomon/.config/ibus/bus/" pid=16919 comm="chromium-browse" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

The code that calls chmod is in ibus_bus_init:

  static void
  ibus_bus_init (IBusBus *bus)
  {
    gchar *path;
    […]
    path = g_path_get_dirname (ibus_get_socket_path ());
    g_mkdir_with_parents (path, 0700);
    g_chmod (path, 0700);
    […]
  }

This is rather harmless, but it could be avoided by checking first the file mode bits on that directory, and do the g_chmod call only if ≠ 0700.

[Impact]

Snaps that build on a xenial stack against libibus will trigger that apparmor denial, and even if actually harmless this will no doubt be reported as a problem by users who inspect the denials generated by their snaps.
The patch (that is already upstream: https://github.com/ibus/ibus/commit/28d0c1d4bc47beb38995d84cc4bb1d539c08a070) fixes that by calling chmod conditionally, only if the file mode bits on the ibus socket path are ≠ 0700.

[Test Case]

Install the chromium snap from the stable channel (version 65.0.3325.181, revision 274 as of this writing), and monitor the system journal for apparmor denials while launching it:

journalctl -f | grep chmod

Observe a denial similar to that one:

Now rebuild the chromium snap with the patched libibus (this can be done by downloading the .snap file, unpacking it with unsquashfs, replacing the libibus files by unpacking the updated deb, then repacking the snap with `snapcraft pack`), install it and launch it while monitoring the system journal.

Observe the denial on chmod is gone.

[Regression Potential]

This is a low-risk, self-contained change. It doesn't change the logic of ibus_bus_init.
ibus input still working in apps (both debs and snaps) should be enough to prove that there are no regressions.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ibus 1.5.17-3ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Apr 5 21:55:30 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-07-02 (642 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: ibus
UpgradeStatus: Upgraded to bionic on 2018-01-29 (66 days ago)

See original description

Tags:

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-05:

Dependencies.txt Edit (7.5 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.0 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (310 bytes, text/plain; charset="utf-8")

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-05:

Some context:

<jdstrand> oSoMoN: perhaps there is an unconditional chmod in the ibus libs. I would argue that should be fixed to only chmod if it isn't what it expects. that would be something for SRU and then anything using the desktop launcher won't be affected by it

<jdstrand> oSoMoN: as it stands, it sounds like if the lib is doing that, *every* snap that uses the part will trigger this denial, which will lead to confused users

<oSoMoN> jdstrand, that denial is harmless though, isn't it?

<jdstrand> oSoMoN: it doesn't seem to affect the snap no. however, there will be bug reports where people think it is causing trouble and people will have to constantly refute that it isn't an issue

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-05:

Issue filed upstream: https://github.com/ibus/ibus/issues/1996, and proposed a fix: https://github.com/ibus/ibus/pull/1997.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2018-04-06:

The fix from Olivier has been commited upstream, that's probably worth backporting to bionic (note that there is already an ibus update in the unapproved queue so a new upload needs to be based on that version)

Changed in ibus (Ubuntu):
assignee:	nobody → Olivier Tilloy (osomon)
importance:	Undecided → Low
status:	New → In Progress

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-06:

Once in bionic, we will want to SRU to xenial so that all snaps that are built with a xenial stack get an updated libibus.

Sebastien Bacher (seb128) on 2018-04-06

Changed in ibus (Ubuntu):
status:	In Progress → Fix Committed

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-04-06:

This bug was fixed in the package ibus - 1.5.17-3ubuntu3

---------------
ibus (1.5.17-3ubuntu3) bionic; urgency=medium

  * debian/patches/ubuntu-conditional-chmod.patch: backport an upstream commit
    to make a call to chmod conditional, to avoid apparmor denials for confined
    apps (e.g. snaps) that use libibus (LP: #1761585)

ibus (1.5.17-3ubuntu2) bionic; urgency=medium

  * debian/patches/ubuntu-unicode-keybinding.patch:
    - use a change proposed/rejected upstream to restore ctrl-shift-u,
      upstream consider it superseeded by the emoji selector but that has
      no keybinding in our ibus version and is not an exact replacement
      (lp: #1760308)

-- Olivier Tilloy <email address hidden> Fri, 06 Apr 2018 11:04:22 +0200

Changed in ibus (Ubuntu):
status:	Fix Committed → Fix Released

Olivier Tilloy (osomon) on 2018-04-06

description:

updated

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-06:

xenial SRU debdiff Edit (2.2 KiB, text/plain)

Bug Watch Updater (bug-watch-updater) on 2018-04-06

Changed in ibus:
status:	Unknown → Fix Released

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2018-04-09: Please test proposed package

Hello Olivier, or anyone else affected,

Accepted ibus into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ibus/1.5.11-1ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in ibus (Ubuntu Xenial):
status:	New → Fix Committed
tags:	added: verification-needed verification-needed-xenial

Revision history for this message

Olivier Tilloy (osomon) wrote on 2018-04-11:

I successfully tested ibus 1.5.11-1ubuntu2.1 from xenial-proposed, following the test case in the bug description:

I installed the chromium snap from the stable channel (version 65.0.3325.181, revision 274) and monitor the system journal for apparmor denials while launching it:

journalctl -f | grep chmod

I observed a denial similar to that one:

I then rebuilt and installed the snap with libibus-1.0-5 and ibus-gtk3 from xenial-proposed (version 1.5.11-1ubuntu2.1):

    cd /tmp
    cp /var/lib/snapd/snaps/chromium_274.snap ./
    unsquashfs chromium_274.snap
    wget https://launchpadlibrarian.net/364009842/libibus-1.0-5_1.5.11-1ubuntu2.1_amd64.deb
    wget https://launchpadlibrarian.net/364009838/ibus-gtk3_1.5.11-1ubuntu2.1_amd64.deb
    dpkg -x ibus-gtk3_1.5.11-1ubuntu2.1_amd64.deb squashfs-root/
    dpkg -x libibus-1.0-5_1.5.11-1ubuntu2.1_amd64.deb squashfs-root/
    snapcraft pack squashfs-root
    snap remove chromium
    snap install --dangerous chromium_65.0.3325.181_amd64.snap
    snap connect chromium:browser-sandbox

I launched it again while monitoring the system journal, and observed that the chmod denial was gone.

I also verified that ibus input still works in the snap (tested with ibus-cangjie for traditional Chinese).

tags:

added: verification-done-xenial
removed: verification-needed-xenial

Revision history for this message

Launchpad Janitor (janitor) wrote on 2018-04-16:

#10

This bug was fixed in the package ibus - 1.5.11-1ubuntu2.1

---------------
ibus (1.5.11-1ubuntu2.1) xenial; urgency=medium

-- Olivier Tilloy <email address hidden> Fri, 06 Apr 2018 15:58:24 +0200

Changed in ibus (Ubuntu Xenial):
status:	Fix Committed → Fix Released

Revision history for this message

Łukasz Zemczak (sil2100) wrote on 2018-04-16: Update Released

#11

The verification of the Stable Release Update for ibus has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.