[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-08 Thread Rüdiger Kupper
For your reference: Bug #1890905

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
Agreed. I'll be referencing this issue there. And I'll have a look into
the journal, thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Jamie Strandboge
I agree that a new bug should be filed. When doing so, please attach any
relevant policy violations from journalctl to the bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Gunnar Hjalmarsson
@Rüdiger: Quite some water has passed under the bridge since the
submission of this bug. It mostly came to be about the method for
achieving a distinguishable abstract path for IBus, and is now closed.

I would suggest that you file a new bug about the issue you now
encounter. It sounds like an apparmor issue to me, and bug #1856738 is
possibly related.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
We are talking about recent Ubuntu focal, thst is: Ubuntu 20.04.1. This
is deemed safe for LTS upgrade! It is not! It will make petfectly
working installs of 18.04 LTS unusable without any warning.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
This will affect many installs, notably in professional multi user
environments. It is absurd assuming that $XDG_CACHE_HOME is unset (any
installation with a few hundred users will have homes on a network share
and consequently caches moved elsewhere).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
Test case: chromium snap with $XDG_CACHE_HOME set.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
Our $XDG_CACHE_HOME points to /var/cache/usercache//
I tried adding /var/cache/usercache/ to @{HOMEDIRS} in apparmor, but it did not 
work. How do I tell my snaps that user caches are in /var/cache/usercache/ ??

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-08-04 Thread Rüdiger Kupper
This is *not* fixed. I still see this issue in a recent install of Ubuntu 
20.04, where $XDG_CACHE_HOME is set.
We have home dirs mounted via network, so user caches were moved to local 
storage to sanitize network load. The right and perfectly valid way of doing so 
is setting $XDG_CACHE_HOME.
Snapd honors this variable, from what I get from related bug reports. 
However, it appears that snaps are still not allowed access to the direcrory 
configured in this environment variable.

This is a production environment for 800+ users who rely on chromium and
Ubuntu. I *really, honestly* need this fixed ASOP.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-02-26 Thread Gunnar Hjalmarsson
** Changed in: ibus (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2020-02-26 Thread Gunnar Hjalmarsson
@Jamie: The code, which changes the abstract socket path from
'unix:tmpdir=/tmp/ibus' to 'unix:tmpdir=$XDG_CACHE_HOME/ibus', was
uploaded to focal via ibus 1.5.21-5ubuntu1 (unix-socket-path.patch).
Mentioned it on bug #1856738 too.

Closing the ibus (ubuntu) task on this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-12-17 Thread Jamie Strandboge
@Gunnar - I am preparing the focal upload now, though there is a parser
bug (bug 1856738) which means I cannot use @{HOME} in the rule and
instead hardcode /home/*/. This will cover all typical situations (ie,
not the atypical /root/.cache/ibus...) except when the user updates
/etc/apparmor.d/tunables/home.d/ to add a different directory for home.
With snaps (this bug) we don't support alternate locations for /home
just yet, so this is not a regression.

We plan to fix that parser bug for 20.04. You may want to hold off on a
1.5.22 upload (or revert the XDG patch) until this is updated to avoid
regression non-snap, ibus abstraction apparmor users with non-default
home.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-09-21 Thread Gunnar Hjalmarsson
@Tyler, @Jamie: When reviewing the proposal in comment #37, Sebastien
pointed at a possible need to also change
/etc/apparmor.d/abstractions/ibus. Can you please consider that?

Also, in Ubuntu 17.10 - 19.04 the im-config change of the abstract
socket path has not been effective in Ubuntu, since we have let GDM
start ibus. Which implications, if any, has that had?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-09-20 Thread Gunnar Hjalmarsson
Reopening the ibus (ubuntu) task.

Background:
The change in ibus 1.5.19-1ubuntu3, which set the abstract socket path to 
'unix:tmpdir=/tmp/ibus', was upstreamed and is now included in the 1.5.21 
source. However, the path proved to not work well on BSD systems:

https://github.com/ibus/ibus/issues/2116

That resulted in a new upstream approach to make the path
indistinguishable, and to make a long story short, the path is about to
be changed in 1.5.22 to 'unix:tmpdir=$XDG_CACHE_HOME/ibus'. To prevent
yet another change in this respect in the ff cycle, I propose that we
change it in eoan again and add two upstream commits so Ubuntu 19.10 is
released with the new (final?) path.

Proposed upload in this PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus

** Bug watch added: github.com/ibus/ibus/issues #2116
   https://github.com/ibus/ibus/issues/2116

** Changed in: ibus (Ubuntu)
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-05-07 Thread Bug Watch Updater
** Changed in: ibus
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-04-26 Thread Launchpad Bug Tracker
This bug was fixed in the package ibus - 1.5.19-1ubuntu3

---
ibus (1.5.19-1ubuntu3) eoan; urgency=medium

  * ubuntu-use-distinguishable-abstract-address.patch:
Change the default address of ibus daemon to 'unix:tmpdir=/tmp/ibus'
so it has a mediatable abstract socket path (LP: #1580463)

 -- Gunnar Hjalmarsson   Thu, 25 Apr 2019 19:01:00
+0200

** Changed in: ibus (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-04-26 Thread Bug Watch Updater
** Changed in: ibus
   Status: Unknown => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-04-26 Thread Gunnar Hjalmarsson
** Bug watch added: github.com/ibus/ibus/issues #2095
   https://github.com/ibus/ibus/issues/2095

** Also affects: ibus via
   https://github.com/ibus/ibus/issues/2095
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ibus/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2019-04-25 Thread Gunnar Hjalmarsson
IBus is not always launched via im-config when GNOME is involved. In
Ubuntu 19.10 im-config will be disabled by default in Wayland sessions.
So to achieve a consistent address of ibus daemon, it's better to change
the default in ibus itself. Attached please find a debdiff with a
proposed fix.

Once this change is in the archive, the equivalent im-config patch can
be dropped.

** Patch added: "ibus-fix-eoan_lp1580463.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1580463/+attachment/5259090/+files/ibus-fix-eoan_lp1580463.debdiff

** Tags added: patch

** Also affects: ibus (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: ibus (Ubuntu Xenial)

** No longer affects: ibus (Ubuntu Yakkety)

** Changed in: ibus (Ubuntu)
   Importance: Undecided => Medium

** Changed in: ibus (Ubuntu)
   Status: New => In Progress

** Changed in: ibus (Ubuntu)
 Assignee: (unassigned) => Gunnar Hjalmarsson (gunnarhj)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package im-config - 0.29-1ubuntu12.2

---
im-config (0.29-1ubuntu12.2) xenial-proposed; urgency=medium

  * debian/patches/use-distinguishable-abstract-address.patch: adjust
ibus-daemon args to include "--address 'unix:tmpdir=/tmp/ibus'" so it has
a mediatable abstract socket path (LP: #1580463)
  * debian/control: Breaks on apparmor << 2.10.95-0ubuntu2.3 since that
adjusts the ibus abstraction to allow applications to communicate with an
ibus-daemon started with "--address 'unix:tmpdir=/tmp/ibus'"

 -- Jamie Strandboge   Fri, 07 Oct 2016 11:37:31 +

** Changed in: im-config (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-27 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
debian/apparmor.service, debian/apparmor.upstart,
debian/lib/apparmor/profile-load: Adjust the checks that previously kept
AppArmor policy from being loaded while booting a container. Now we
attempt to load policy if we're in a LXD or LXC managed container that is
using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
interrupted by failing tests whenever the AppArmor stacking features are
backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
receives a 4.8 or newer kernel
- debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
  exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
- debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
  exec_stack.sh fix mentioned above to more accurately test kernels older
  than 4.8 (LP: #1630069)
- debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
  patch earlier in the series, as to match when it was committed upstream,
  so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks   Fri, 07 Oct 2016 05:21:44 +

** Changed in: apparmor (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-26 Thread Tyler Hicks
I've completed the AppArmor test plan:

  https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor

I've also manually verified the AppArmor portion of this SRU.

** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-25 Thread Jamie Strandboge
FYI, im-config is verification-done. I didn't do full SRU testing for
AppArmor. Tyler, when you are done with the SRU testing, feel free to
mark this as verification-done.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-25 Thread Jamie Strandboge
Just for clarity, I did both the main test case and the extended test
case for im-config. I also noticed that when installing im-config, it
correctly required the updated apparmor.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-13 Thread Martin Pitt
Hello Sebastien, or anyone else affected,

Accepted im-config into xenial-proposed. The package will build now and
be available at https://launchpad.net/ubuntu/+source/im-
config/0.29-1ubuntu12.2 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 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 to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

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

** Changed in: im-config (Ubuntu Xenial)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-07 Thread Jamie Strandboge
** Description changed:

  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.
  
  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.
  
  [Test Case]
  1. start a unity session before updating to the package in -proposed
  
  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76
  
  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM
  
  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before
  
  5. logout of unity, then log back in
  
  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e
  
  (notice '/tmp/ibus/' in the path)
  
  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...
  
  (notice '@/tmp/ibus/' in the path)
  
  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting 'Text
  Entry'. From there, add an input source on the right, make sure 'Show
  current input source in the menu bar' is checked, then use the input
  source panel indicator to change input sources.
  
  Extended test case to verify input support still works in unconfined and
  confined applications:
  
  1. Systems Settings Language Support, if prompted install the complete 
language support
  2. Install Chinese (simple and traditional)
  3. sudo apt-get install ibus-pinyin ibus-sunpinyin
  4. logout / login
  5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
  6. select pinyin from the indicator
  7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
  8. open gnome-calculator and try to type something in (should get a pop-up)
  9. open evince and try to search a pdf (should get a pop up)
  10. upgrade apparmor and im-config from xenial-proposed
  11. logout and back in
  12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/...
  13. open gnome-calculator and try to type something in (should get a pop-up)
  14. open evince and try to search a pdf (should get a pop up)
  15. verify no new apparmor denials
  
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only occur after ibus-daemon is
  restarted, which is upon session start, not package upgrade. When it is
  restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated
  accordingly for other applications to pick up.
  
  This change intentionally requires a change to the unity7 snapd
  interface, which is in already done.
  
  This change intentionally requires a change to apparmor to add a unix
  rule for communicating with the new ibus address. This is in xenial-
  proposed 2.10.95-0ubuntu2.3 (and 2.10.95-0ubuntu2.4). The packages
  changes to im-config use 'Breaks: apparmor (<< 2.10.95-0ubuntu2.3) to
  ensure that the apparmor abstraction is updated and policy recompiled
  before ibus is restarted. This was omitted from the initial im-config
  upload which resulted in bug #1588197. Test cases ensuring this is
- working properly is included above under 'Extended test case'.
+ working properly are included above under 'Extended test case'.
  
  = SRU apparmor =
  [Impact]
  The upload that adjusts ibus-daemon to start with "--address 
'unix:tmpdir=/tmp/ibus'" causes the ibus AppArmor abstraction to no longer be 
sufficient due to the lack of a rule for the new socket path. This upload adds 
such a rule.
  
  [Test Case]
  1. Start a unity session after updating to the im-config package in -proposed 
but before the apparmor package in -proposed
  
  2. Use the ibus client program to list the available engines
  $ ibus list-engine
  language: Spanish; Castilian
    xkb:latam::spa - Spanish (Latin American)
    xkb:es::spa - Spanish
  language: Slovak
    xkb:sk:qwerty:slo - Slovak (qwerty)
    xkb:sk::slo - Slovak
  ...
  
  3. Create an AppArmor profile file, called ibus, with the following
  contents:
  
  #include 
  
  

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-07 Thread Jamie Strandboge
im-config 0.29-1ubuntu12.2 is uploaded to xenial-proposed and ensures
the newer apparmor is installed. Please see the updated description for
im-config in Test Case and Regression Potential for details.

** Description changed:

  IMPORTANT: SRU Team, see comment #25 for why this bug is temporarily
  marked verification-failed
  
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.
  
  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.
  
  [Test Case]
  1. start a unity session before updating to the package in -proposed
  
  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76
  
  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM
  
  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before
  
  5. logout of unity, then log back in
  
  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e
  
  (notice '/tmp/ibus/' in the path)
  
  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...
  
  (notice '@/tmp/ibus/' in the path)
  
  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting 'Text
  Entry'. From there, add an input source on the right, make sure 'Show
  current input source in the menu bar' is checked, then use the input
  source panel indicator to change input sources.
  
+ 
+ Extended test case to verify input support still works in unconfined and 
confined applications:
+ 
+ 1. Systems Settings Language Support, if prompted install the complete 
language support
+ 2. Install Chinese (simple and traditional)
+ 3. sudo apt-get install ibus-pinyin ibus-sunpinyin
+ 4. logout / login
+ 5. System Settings / Text Entry - add Chinese (Pinyin) (IBus)
+ 6. select pinyin from the indicator
+ 7. sudo lsof | grep ibus | grep @ # will use @/tmp/dbus-...
+ 8. open gnome-calculator and try to type something in (should get a pop-up)
+ 9. open evince and try to search a pdf (should get a pop up)
+ 10. upgrade apparmor and im-config from xenial-proposed
+ 11. logout and back in
+ 12. sudo lsof | grep ibus | grep @ # will use @/tmp/ibus/...
+ 13. open gnome-calculator and try to type something in (should get a pop-up)
+ 14. open evince and try to search a pdf (should get a pop up)
+ 15. verify no new apparmor denials
+ 
+ 
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only occur after ibus-daemon is
  restarted, which is upon session start, not package upgrade. When it is
  restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated
  accordingly for other applications to pick up.
  
  This change intentionally requires a change to the unity7 snapd
- interface, which is in progress. Currently the change should not regress
- snapdsbehavior due to other issues surrounding using ibus unrelated to
- security policy.
+ interface, which is in already done.
+ 
+ This change intentionally requires a change to apparmor to add a unix
+ rule for communicating with the new ibus address. This is in xenial-
+ proposed 2.10.95-0ubuntu2.3 (and 2.10.95-0ubuntu2.4). The packages
+ changes to im-config use 'Breaks: apparmor (<< 2.10.95-0ubuntu2.3) to
+ ensure that the apparmor abstraction is updated and policy recompiled
+ before ibus is restarted. This was omitted from the initial im-config
+ upload which resulted in bug #1588197. Test cases ensuring this is
+ working properly is included above under 'Extended test case'.
+ 
  
  = SRU apparmor =
  [Impact]
  The upload that adjusts ibus-daemon to start with "--address 
'unix:tmpdir=/tmp/ibus'" causes the ibus AppArmor abstraction to no longer be 
sufficient due to the lack of a rule for the new socket path. This upload adds 
such a rule.
  
  [Test Case]
  1. Start a unity session after updating to the im-config package in -proposed 
but before the 

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-10-06 Thread Tyler Hicks
** Description changed:

  IMPORTANT: SRU Team, see comment #25 for why this bug is temporarily
  marked verification-failed
  
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.
  
  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.
  
  [Test Case]
  1. start a unity session before updating to the package in -proposed
  
  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76
  
  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM
  
  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before
  
  5. logout of unity, then log back in
  
  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e
  
  (notice '/tmp/ibus/' in the path)
  
  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...
  
  (notice '@/tmp/ibus/' in the path)
  
  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting 'Text
  Entry'. From there, add an input source on the right, make sure 'Show
  current input source in the menu bar' is checked, then use the input
  source panel indicator to change input sources.
  
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only occur after ibus-daemon is
  restarted, which is upon session start, not package upgrade. When it is
  restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated
  accordingly for other applications to pick up.
  
  This change intentionally requires a change to the unity7 snapd
  interface, which is in progress. Currently the change should not regress
  snapdsbehavior due to other issues surrounding using ibus unrelated to
  security policy.
  
  = SRU apparmor =
  [Impact]
  The upload that adjusts ibus-daemon to start with "--address 
'unix:tmpdir=/tmp/ibus'" causes the ibus AppArmor abstraction to no longer be 
sufficient due to the lack of a rule for the new socket path. This upload adds 
such a rule.
  
  [Test Case]
  1. Start a unity session after updating to the im-config package in -proposed 
but before the apparmor package in -proposed
  
  2. Use the ibus client program to list the available engines
  $ ibus list-engine
  language: Spanish; Castilian
    xkb:latam::spa - Spanish (Latin American)
    xkb:es::spa - Spanish
  language: Slovak
    xkb:sk:qwerty:slo - Slovak (qwerty)
    xkb:sk::slo - Slovak
  ...
  
  3. Create an AppArmor profile file, called ibus, with the following
  contents:
  
  #include 
  
  profile ibus {
    #include 
    #include 
    #include 
  
    /usr/bin/ibus mr,
  
  }
  
  4. Load the profile
  $ sudo apparmor_parser -qr ibus
  
  5. Rerun the ibus client program under confinement to see that it fails
  $ aa-exec -p ibus -- ibus list-engine
  Can't connect to IBus.
  
  6. Note the AppArmor denial in the syslog
  
  audit: type=1400 audit(1472252079.589:57): apparmor="DENIED"
  operation="connect" profile="ibus" pid=5364 comm="ibus" family="unix"
  sock_type="stream" protocol=0 requested_mask="send receive connect"
  denied_mask="send connect" addr=none peer_addr="@/tmp/ibus/dbus-
  kxnhAsmv" peer="unconfined"
  
  7. Update to the apparmor package in -proposed
  
- 8. Rerun the ibus client program under confinement to see that it works
+ 8. Reload the profile
+ $ sudo apparmor_parser -qr ibus
  
+ 9. Rerun the ibus client program under confinement to see that it works
  $ aa-exec -p ibus -- ibus list-engine
  language: Spanish; Castilian
    xkb:latam::spa - Spanish (Latin American)
    xkb:es::spa - Spanish
  language: Slovak
    xkb:sk:qwerty:slo - Slovak (qwerty)
    xkb:sk::slo - Slovak
  ...
  
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only add additional rules to the
  apparmor ibus abstraction.
  
  

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-09-26 Thread Tyler Hicks
Swapping verification-failed for verification-needed now that bug
1579135 has been fixed for ~1 week.

** Tags removed: verification-failed
** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-09-01 Thread Tyler Hicks
I'm temporarily marking this SRU bug as verification-failed so that it
doesn't get let through until kernel bug 1579135 is fixed. Without the
kernel bug fix for bug 1579135, this SRU has the potential for oopsing
the kernel of some users. Lets sit on this SRU until the Xenial kernel
currently in -proposed has been released for ~1 week to give users some
time to upgrade and reboot.

** Tags removed: verification-needed
** Tags added: verification-failed

** Description changed:

+ IMPORTANT: SRU Team, see comment #25 for why this bug is temporarily
+ marked verification-failed
+ 
  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.
  
  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.
  
  [Test Case]
  1. start a unity session before updating to the package in -proposed
  
  2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76
  
  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM
  
  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before
  
  5. logout of unity, then log back in
  
  6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e
  
  (notice '/tmp/ibus/' in the path)
  
  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...
  
  (notice '@/tmp/ibus/' in the path)
  
  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting 'Text
  Entry'. From there, add an input source on the right, make sure 'Show
  current input source in the menu bar' is checked, then use the input
  source panel indicator to change input sources.
  
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only occur after ibus-daemon is
  restarted, which is upon session start, not package upgrade. When it is
  restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated
  accordingly for other applications to pick up.
  
  This change intentionally requires a change to the unity7 snapd
  interface, which is in progress. Currently the change should not regress
  snapdsbehavior due to other issues surrounding using ibus unrelated to
  security policy.
  
  = SRU apparmor =
  [Impact]
  The upload that adjusts ibus-daemon to start with "--address 
'unix:tmpdir=/tmp/ibus'" causes the ibus AppArmor abstraction to no longer be 
sufficient due to the lack of a rule for the new socket path. This upload adds 
such a rule.
  
  [Test Case]
  1. Start a unity session after updating to the im-config package in -proposed 
but before the apparmor package in -proposed
  
  2. Use the ibus client program to list the available engines
  $ ibus list-engine
  language: Spanish; Castilian
-   xkb:latam::spa - Spanish (Latin American)
-   xkb:es::spa - Spanish
+   xkb:latam::spa - Spanish (Latin American)
+   xkb:es::spa - Spanish
  language: Slovak
-   xkb:sk:qwerty:slo - Slovak (qwerty)
-   xkb:sk::slo - Slovak
+   xkb:sk:qwerty:slo - Slovak (qwerty)
+   xkb:sk::slo - Slovak
  ...
  
  3. Create an AppArmor profile file, called ibus, with the following
  contents:
  
  #include 
  
  profile ibus {
-   #include 
-   #include 
-   #include 
+   #include 
+   #include 
+   #include 
  
-   /usr/bin/ibus mr,
+   /usr/bin/ibus mr,
  
  }
  
  4. Load the profile
  $ sudo apparmor_parser -qr ibus
  
  5. Rerun the ibus client program under confinement to see that it fails
  $ aa-exec -p ibus -- ibus list-engine
  Can't connect to IBus.
  
  6. Note the AppArmor denial in the syslog
  
  audit: type=1400 audit(1472252079.589:57): apparmor="DENIED"
  operation="connect" profile="ibus" pid=5364 comm="ibus" family="unix"
  sock_type="stream" protocol=0 requested_mask="send receive connect"
  denied_mask="send connect" addr=none peer_addr="@/tmp/ibus/dbus-
  kxnhAsmv" peer="unconfined"
  
  7. Update to the apparmor package in 

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-08-29 Thread Chris J Arges
Hello Sebastien, or anyone else affected,

Accepted apparmor into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.3 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 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 to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

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

** Changed in: apparmor (Ubuntu Xenial)
   Status: Triaged => Fix Committed

** Tags removed: verification-done

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-08-28 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.10.95-4ubuntu4

---
apparmor (2.10.95-4ubuntu4) yakkety; urgency=medium

  * debian/patches/allow-access-to-ibus-socket.patch: Adjust the ibus
abstraction to allow access to the abstract UNIX domain socket location
used in Ubuntu. (LP: #1580463)
  * debian/lib/apparmor/functions: Quiet the "Files ... and ... differ"
output, during the update process, which was printed by diff. This message
left users concerned since it mentioned md5sums files without being clear
about what was happening. (LP: #1614215)

 -- Tyler Hicks   Fri, 26 Aug 2016 13:33:46 -0500

** Changed in: apparmor (Ubuntu Yakkety)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-08-26 Thread Launchpad Bug Tracker
** Branch linked: lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs


[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-08-26 Thread Tyler Hicks
** Description changed:

  = SRU im-config =
  [Impact]
  ibus-daemon by default uses a unix socket name of /tmp/dbus-... that is 
indistinguishable from dbus-daemon abstract sockets. While dbus-daemon has 
AppArmor mediation, ibus-daemon does not so it is important that its abstract 
socket not be confused with dbus-daemon's. By modifying ibus-daemon's start 
arguments to use "--address 'unix:tmpdir=/tmp/ibus'" AppArmor can continue 
mediating DBus abstract sockets like normal and also mediate access to the 
ibus-daemon-specific abstract socket via unix rules. This also tidies up the 
abstract socket paths so that it is clear which are for ibus-daemon, which for 
dbus-daemon, etc.
  
  The upload simply adjusts 21_ibus.rc to start ibus-daemon with "--
  address 'unix:tmpdir=/tmp/ibus'" and adds a comment. No compiled code
  changes are required.
  
  [Test Case]
  1. start a unity session before updating to the package in -proposed
  
- 2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0 
+ 2. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/dbus-Vyx8fGFA,guid=28e8e7e89f902c8d4e9d77c5557add76
  
  3. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 2973 jamie8u unix 0x  0t0   29606 
@/tmp/dbus-oxKYpN30 type=STREAM
  
  4. update the package in -proposed and perform '2' and '3'. The
  IBUS_ADDRESSES should be the same as before
  
  5. logout of unity, then log back in
  
- 6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0 
+ 6. $ grep IBUS_ADDRESS ~/.config/ibus/bus/*-unix-0
  
IBUS_ADDRESS=unix:abstract=/tmp/ibus/dbus-SpxOl8Fc,guid=06d4bbeb07614c6dffbf221c57473f4e
  
  (notice '/tmp/ibus/' in the path)
  
  7. $ lsof -p $(pidof ibus-daemon) | grep '/dbus'
  ibus-daem 3471 jamie8u unix 0x  0t0  26107 
@/tmp/ibus/dbus-SpxOl8Fc type=STREAM
  ...
  
  (notice '@/tmp/ibus/' in the path)
  
  In addition to the above, you can test for regressions by opening
  'System Settings' under the 'gear' icon in the panel and selecting 'Text
  Entry'. From there, add an input source on the right, make sure 'Show
  current input source in the menu bar' is checked, then use the input
  source panel indicator to change input sources.
  
  [Regression Potential]
  
  The regression potential is considered low because there are no compiled
  code changes and because the changes only occur after ibus-daemon is
  restarted, which is upon session start, not package upgrade. When it is
  restarted, the files in ~/.config/ibus/bus/*-unix-0 are updated
  accordingly for other applications to pick up.
  
  This change intentionally requires a change to the unity7 snapd
  interface, which is in progress. Currently the change should not regress
  snapdsbehavior due to other issues surrounding using ibus unrelated to
  security policy.
  
+ = SRU apparmor =
+ [Impact]
+ The upload that adjusts ibus-daemon to start with "--address 
'unix:tmpdir=/tmp/ibus'" causes the ibus AppArmor abstraction to no longer be 
sufficient due to the lack of a rule for the new socket path. This upload adds 
such a rule.
+ 
+ [Test Case]
+ 1. Start a unity session after updating to the im-config package in -proposed 
but before the apparmor package in -proposed
+ 
+ 2. Use the ibus client program to list the available engines
+ $ ibus list-engine
+ language: Spanish; Castilian
+   xkb:latam::spa - Spanish (Latin American)
+   xkb:es::spa - Spanish
+ language: Slovak
+   xkb:sk:qwerty:slo - Slovak (qwerty)
+   xkb:sk::slo - Slovak
+ ...
+ 
+ 3. Create an AppArmor profile file, called ibus, with the following
+ contents:
+ 
+ #include 
+ 
+ profile ibus {
+   #include 
+   #include 
+   #include 
+ 
+   /usr/bin/ibus mr,
+ 
+ }
+ 
+ 4. Load the profile
+ $ sudo apparmor_parser -qr ibus
+ 
+ 5. Rerun the ibus client program under confinement to see that it fails
+ $ aa-exec -p ibus -- ibus list-engine
+ Can't connect to IBus.
+ 
+ 6. Note the AppArmor denial in the syslog
+ 
+ audit: type=1400 audit(1472252079.589:57): apparmor="DENIED"
+ operation="connect" profile="ibus" pid=5364 comm="ibus" family="unix"
+ sock_type="stream" protocol=0 requested_mask="send receive connect"
+ denied_mask="send connect" addr=none peer_addr="@/tmp/ibus/dbus-
+ kxnhAsmv" peer="unconfined"
+ 
+ 7. Update to the apparmor package in -proposed
+ 
+ 8. Rerun the ibus client program under confinement to see that it works
+ 
+ $ aa-exec -p ibus -- ibus list-engine
+ language: Spanish; Castilian
+   xkb:latam::spa - Spanish (Latin American)
+   xkb:es::spa - Spanish
+ language: Slovak
+   xkb:sk:qwerty:slo - Slovak (qwerty)
+   xkb:sk::slo - Slovak
+ ...
+ 
+ [Regression Potential]
+ 
+ The regression potential is considered low because there are no compiled
+ code changes and because the changes only add additional rules to the
+ apparmor ibus abstraction.
+ 
  = Original description =
  Currently snaps can't access ibus/fcitx from the system, do we need a 
interface for input methods 

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-07-27 Thread Launchpad Bug Tracker
This bug was fixed in the package snapd - 2.11+16.10

---
snapd (2.11+16.10) yakkety; urgency=medium

  * New upstream release: LP: #1605303
- increase version number to reflect the nature of the update
  better
- store, daemon, client, cmd/snap, docs/rest.md: adieu search
  grammar
- debian: move snapd.refresh.timer into timers.target
- snapstate: add daemon-reload to fix autopkgtest on yakkety
- Interfaces: hardware-observe
- snap: rework the output after a snap operation
- daemon, cmd/snap: refresh --devmode
- store, daemon, client, cmd/snap: implement `snap find --private`
- tests: add network-observe interface spread test
- interfaces/builtin: allow getsockopt for connected x11 plugs
- osutil: check for nogrup instead of adm
- store: small cleanups (more needed)
- snap/squashfs: fix test not to hardcode snap size
- client,cmd/snap: cleanup cmd/snap test suite, add extra args
  testThis cleans up the cmd/snap test suite:
- wrappers: map "never" restart condition to "no."
- wrappers: run update-desktop-database after add/remove of desktop
  files
- release: work around elementary mistake
- many: remove all traces of channel from the buying codepath
- store: kill setUbuntuStoreHeaders
- docs: add payment methods documentation
- many: present user with a choice of payment backends
- asserts: add cross checks for snap asserts
- cmd/snap,cmd/snap-exec: support running hooks via snap-exec.
- tests: improve snap run symlink tests
- tests: add content sharing interface spread test
- store & many: a mechanical branch shortening store names
- snappy: remove old snappy pkg
- overlord/snapstate: kill flagscompat
- overlord/snapstate, daemon, client, cmd/snap: devmode override
  (aka confined)
- tests: extend refresh test to talk to the staging and production
  stores
- asserts,daemon: cross checks for account and account-key
  assertions
- client: existing JSON fixtures uses tabs for indentation
- snap-exec: add proper integration test for snap-exec
- spread.yaml, tests: replace hello-world with test-snapd-tools
- tests: add locale-control interface spread test
- tests: add mount-observe interface spread test
- tests: add system-observe interface spread test
- many: add AuthContext to mediate user updates to the state
- store/auth: add helper for the macaroon refresh endpoint
- cmd: add buy command
- overlord: switch snapstate.Update to use ListRefresh (aka
  /snaps/metadata)
- snap-exec: fix silly off-by-one error
- tests: stop using hello-world.echo in the tests
- tests: add env command to test-snapd-tools
- classic: remove (most of) "classic" mode, this is implemented as a
  snap now
- many: remove snapstate.Candidate and other cleanups
- many: removed authenticator, store gets a user instead
- asserts: fix minor doc comment typo
- snap: ensure unknown arguments to `snap run` are ignored
- overlord/auth: add Device/SetDevice to persist device identity in
  state
- overlord: make SyncBoot work again
- tests: add -y flag to apt autoremove command in unity task restore
- many: migrate SnapSetup and SideInfo to use RealName
- daemon: drop auther()
- client: improve error from client.do() on json decode failures
- tests: readd the fake store tests
- many: allow removal of broken snaps, add spread test
- overlord: implement {After: duration} support for handlers
- interface: add new interfaces.all.SecurityBackends
- integration-tests: remove login tests
- cmd,interfaces,snap: implement hook whitelist.
- daemon,overlord/auth,store: update macaroon authentication to use
  the new endpoints
- daemon, overlord: add buy endpoint to REST API
- tests: use systemd-run for starting and stopping the unity app
- tests, integration-tests: port systemd service check test to
  spread
- store: switch search to new snap-specific endpoint
- store, many: start using the new details endpoint
- tests, integration-tests: port unity test to spread
- tests: add spread test for tried snaps removal
- tests, integration-tests: port auth errors test to spread
- snapstate: rename OfficialName to RealName in the new tests
- many: rename SideInfo.OfficialName to SideInfo.RealName
- snapstate: use snapstate.Type in backend.RemoveSnapFiles
- many: add `snap enable/disable` commands
- tests, integration-tests: port refresh all test to spread
- snap: add `snap run --shell`
- tests: set yaml indentation to 4 spaces
- snapstate: cleanup downloaded temp snap files
- overlord: make patch1_test more robust
- debian: add snapd.postrm that purges
- integration-tests: drop already covered refresh app test
- many: add concept of "broken" snaps
- tests, integration-tests: 

[Bug 1580463] Re: Snap blocks access to system input methods (ibus, fcitx, ...)

2016-06-20 Thread Anthony Wong
** Summary changed:

- Snap blocks access to system input methods (ibus, fctix, ...)
+ Snap blocks access to system input methods (ibus, fcitx, ...)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1580463

Title:
  Snap blocks access to system input methods (ibus, fcitx, ...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1580463/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs