** Description changed: 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 could be avoided by checking first the file mode bits on that - directory, and do the g_chmod call only if ≠ 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: + + 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 + + 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 + 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)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1761585 Title: ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus To manage notifications about this bug go to: https://bugs.launchpad.net/ibus/+bug/1761585/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
