VM permanently tries to read /dev/shm/lttng-ust-wait-5

Status changed to 'Confirmed' because the bug affects multiple users.

We should not allow access to /dev/shm/lttng-ust-wait-5 to VMs unless libvirt exposes the files in the domain definition and virt-aa-helper can update the policy on a per VM basis. We could add a rule to the libvirt-qemu abstraction, but it would be too generic 'owner /dev/shm/lttng-ust-wait-* rw,' and therefore break guest isolation (though that is of course fine for users to manually add if they need this functionality and understand the compromise).

So maybe it should be explicitly denied to avoid the log flooding ? But the question remains: why should VMs access this file?

Increasing the priority of this since this blocks normal users of qemu-system-x86 from even creating VMs.

The following illustrates the dependencies:
qemu-system-x86 -> librados2 -> liblttng-ust0

So either we should remove the dependencies here such that LTTng isn't being installed by default, or amend the apparmor profile so that it can accommodate this.

Please remove the dependency on liblttng-ust0 since it breaks guest isolation.

Another option is making the failure to open /dev/shm/lttng-ust-wait-* non-fatal. This is what Ubuntu Touch does on app launch.

I should have been more clear with this comment: "Please remove the dependency on liblttng-ust0 since it breaks guest isolation."

Please remove the dependency on liblttng-ust0, make the failure to open /dev/shm/lttng-ust-wait-* non-fatal or put the lttng file in a guest-specific directory. Modifying the apparmor policy to allow /dev/shm/lttng-ust-wait-* is not an option because it breaks guest isolation.

This bug was fixed in the package libvirt - 1.2.12-0ubuntu8

---------------
libvirt (1.2.12-0ubuntu8) vivid; urgency=medium

  * silence denial of attempted reads of lttng files (LP: #1432644)
 -- Serge Hallyn <email address hidden> Fri, 27 Mar 2015 21:36:27 -0500

With libvirt 1.2.12-0ubuntu8 being installed, virsh still fails to start an LXC operating system container, resulting in the following dmesg:

[ 126.832553] audit: type=1400 audit(1427571328.167:150): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/shm/lttng-ust-wait-5" pid=4285 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 126.832646] audit: type=1400 audit(1427571328.167:151): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/shm/lttng-ust-wait-5" pid=4285 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 127.195264] audit: type=1400 audit(1427571328.527:152): apparmor="STATUS" operation="profile_remove" profile="unconfined" name="libvirt-9d578815-a1e9-4596-aef9-a70717574f0e" pid=4310 comm="apparmor_parser"

@haraldhetzner

please show the xml for the contianer which is failing to start.

This is the XML (virsh -c lxc:/// dumpxml test):

<domain type='lxc'>
  <name>test</name>
  <uuid>9d578815-a1e9-4596-aef9-a70717574f0e</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64'>exe</type>
    <init>/sbin/init</init>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/lib/libvirt/libvirt_lxc</emulator>
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/lxc/test/rootfs'/>
      <target dir='/'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='00:16:00:69:5b:88'/>
      <source bridge='virbr0'/>
      <guest dev='eth0' actual='vnet1'/>
    </interface>
    <console type='pty'>
      <target type='lxc' port='0'/>
    </console>
  </devices>
</domain>

I looked into this with libvirt-lxc and can confirm that the domains to not start, but the apparmor denial is a red herring. Ie, if I add this to /etc/apparmor.d/abstractions/libvirt-lxc:
   /dev/shm/lttng-ust-wait-* rw,

and this to /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper:
  /dev/shm/lttng-ust-wait-* rw,

Then do:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper

I can try to start a container with:
$ virsh -c lxc:// start o1
error: Failed to start domain o1
error: internal error: guest failed to start: Message did not receive a reply (timeout by message bus)

but there are no denials.

Serge, feel free to add an explicit deny in /etc/apparmor.d/abstractions/libvirt-* and an allow rule for /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper, but know that won't fix this bug.

I have applied the update on vivid, and creating a new VM still fails:

Unable to complete install: 'internal error: process exited while connecting to monitor: libust[443/443]: Warning: HOME environment variable not set. Disabling LTTng-UST per-user tracing. (in setup_local_apps() at lttng-ust-comm.c:375)
libust[443/445]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:958)
libust[443/445]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:958)
2015-03-31T13:21:23.715646Z qemu-system-x86_64: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fedora20-cloud.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied

In my log:

[14770.402367] audit: type=1400 audit(1427808083.050:26): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/shm/lttng-ust-wait-5" pid=400 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[14770.402404] audit: type=1400 audit(1427808083.050:27): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/shm/lttng-ust-wait-5" pid=400 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[14770.772184] audit: type=1400 audit(1427808083.422:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-5b2de2b1-0776-4d51-92cc-c4356daa075a" pid=441 comm="apparmor_parser"
[14770.796265] audit: type=1400 audit(1427808083.446:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="qemu_bridge_helper" pid=441 comm="apparmor_parser"
[14771.000518] audit: type=1400 audit(1427808083.650:30): apparmor="DENIED" operation="open" profile="libvirt-5b2de2b1-0776-4d51-92cc-c4356daa075a" name="/sys/devices/system/node/" pid=443 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
[14771.000541] audit: type=1400 audit(1427808083.650:31): apparmor="DENIED" operation="open" profile="libvirt-5b2de2b1-0776-4d51-92cc-c4356daa075a" name="/sys/devices/system/cpu/" pid=443 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0

Am I missing something?

I missed the last message from the log, sorry:

audit: type=1400 audit(1427810727.733:51): apparmor="DENIED" operation="mknod" profile="libvirt-5b2de2b1-0776-4d51-92cc-c4356daa075a" name="/var/lib/libvirt/qemu/channel/target/fedora20-cloud.org.qemu.guest_agent.0" pid=3147 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=119 ouid=119

Discussed with Serge and we're going to disable the lttng support in ceph for vivid - needs to be a little less hard than it is right now.

raising a ceph task.

This bug was fixed in the package ceph - 0.93-0ubuntu6

---------------
ceph (0.93-0ubuntu6) vivid; urgency=medium

  * d/control,rules,*.symbols: Disable lttng support until we can make
    it play a bit nicer with libvirt and apparmor, drop associated
    symbols (LP: #1432644).
 -- James Page <email address hidden> Wed, 01 Apr 2015 10:37:03 +0100

I don't understand how this is going to help, as I don't have/use ceph. Anyway, the problem still exists. Is there a way to completely disable apparmor for libvirt temporarily, until a fix can be found, as I *really* need it to work? Of course I could revert to 14.10, but I am trying to help find bugs in 15.04, so that's really not an option.

Sorry for not being clearer, I got rid of liblttng-ust0, but it still fails:

Unable to complete install: 'internal error: process exited while connecting to monitor: 2015-04-02T11:15:40.061933Z qemu-system-x86_64: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied
'
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1819, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 403, in start_install
    noboot)
  File "/usr/share/virt-manager/virtinst/guest.py", line 467, in _create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3422, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error: process exited while connecting to monitor: 2015-04-02T11:15:40.061933Z qemu-system-x86_64: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied

journalctl -f:
april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/node/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/cpu/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.093:50): apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/node/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.093:51): apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/cpu/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="mknod" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0" pid=23690 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=119 ouid=119
april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.137:52): apparmor="DENIED" operation="mknod" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0" pid=23690 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=119 ouid=119
april 02 13:17:54 monster systemd-machined[23691]: Machine qemu-fedora20-2 terminated.
april 02 13:17:54 monster libvirt...

Quoting Petter Adsen (<email address hidden>):
> Sorry for not being clearer, I got rid of liblttng-ust0, but it still
> fails:
>
> Unable to complete install: 'internal error: process exited while connecting to monitor: 2015-04-02T11:15:40.061933Z qemu-system-x86_64: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied
> '
> Traceback (most recent call last):
> File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
> callback(asyncjob, *args, **kwargs)
> File "/usr/share/virt-manager/virtManager/create.py", line 1819, in do_install
> guest.start_install(meter=meter)
> File "/usr/share/virt-manager/virtinst/guest.py", line 403, in start_install
> noboot)
> File "/usr/share/virt-manager/virtinst/guest.py", line 467, in _create_guest
> dom = self.conn.createLinux(start_xml or final_xml, 0)
> File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3422, in createLinux
> if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
> libvirtError: internal error: process exited while connecting to monitor: 2015-04-02T11:15:40.061933Z qemu-system-x86_64: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0,server,nowait: Failed to bind socket: Permission denied
>
> journalctl -f:
> april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/node/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
> april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/cpu/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
> april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.093:50): apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/node/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
> april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.093:51): apparmor="DENIED" operation="open" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/sys/devices/system/cpu/" pid=23690 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 ouid=0
> april 02 13:17:54 monster audit[23690]: <audit-1400> apparmor="DENIED" operation="mknod" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0" pid=23690 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=119 ouid=119
> april 02 13:17:54 monster kernel: audit: type=1400 audit(1427973474.137:52): apparmor="DENIED" operation="mknod" profile="libvirt-3d049f0b-f90d-4ef6-af58-6a2e2b238adb" name="/var/lib/libvirt/qemu/channel/target/fedora20-2.org.qemu.guest_agent.0" pid=23690 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=119 ouid=119
> april 02 13:17:54 monster sy...

FWIW, we are disabling the lttng support in the final hammer release to avoid this issue (until we come up with a better solution).

None of the solutions provided work for me.

root@compute1:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"

root@compute1:~# dpkg -l | grep libvirt
ii libvirt-bin 1.2.12-0ubuntu13~cloud0 amd64 programs for the libvirt library
ii libvirt0 1.2.12-0ubuntu13~cloud0 amd64 library for interfacing with different virtualization systems
ii nova-compute-libvirt 1:2014.2.3-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support
ii python-libvirt 1.2.2-0ubuntu2 amd64 libvirt Python bindings

root@compute1:~# aa-complain /etc/apparmor.d/usr.sbin.libvirtd
Setting /etc/apparmor.d/usr.sbin.libvirtd to complain mode.

root@compute1:~# service libvirt-bin restart
libvirt-bin stop/waiting
libvirt-bin start/running, process 19311

root@compute1:~# tail /var/log/syslog
Jun 30 20:10:15 localhost kernel: [5209244.436201] type=1400 audit(1435709415.215:1986158): apparmor="DENIED" operation="open" profile="libvirt-4a554600-47e6-4654-87bf-66d8c68bfdcb" name="/run/shm/lttng-ust-wait-5" pid=6082 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:17 localhost kernel: [5209247.156976] type=1400 audit(1435709417.935:1986159): apparmor="DENIED" operation="open" profile="libvirt-9393961e-4385-46f4-bd81-a17368bedcac" name="/run/shm/lttng-ust-wait-5" pid=23521 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:20 localhost kernel: [5209249.440373] type=1400 audit(1435709420.215:1986160): apparmor="DENIED" operation="open" profile="libvirt-4a554600-47e6-4654-87bf-66d8c68bfdcb" name="/run/shm/lttng-ust-wait-5" pid=6082 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:20 localhost kernel: [5209250.008276] ip_set: protocol 6
Jun 30 20:10:22 localhost kernel: [5209252.161148] type=1400 audit(1435709422.935:1986161): apparmor="DENIED" operation="open" profile="libvirt-9393961e-4385-46f4-bd81-a17368bedcac" name="/run/shm/lttng-ust-wait-5" pid=23521 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:25 localhost kernel: [5209254.444532] type=1400 audit(1435709425.215:1986162): apparmor="DENIED" operation="open" profile="libvirt-4a554600-47e6-4654-87bf-66d8c68bfdcb" name="/run/shm/lttng-ust-wait-5" pid=6082 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:27 localhost kernel: [5209257.165333] type=1400 audit(1435709427.935:1986163): apparmor="DENIED" operation="open" profile="libvirt-9393961e-4385-46f4-bd81-a17368bedcac" name="/run/shm/lttng-ust-wait-5" pid=23521 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0
Jun 30 20:10:30 localhost kernel: [5209259.448704] type=1400 audit(1435709430.215:1986164): apparmor="DENIED" operation="open" profile="libvirt-4a554600-47e6-4654-87bf-66d8c68bfdcb" name="/run/shm/lttng-ust-wait-5" pid=6082 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid...

George, if you want to allow the lttng accesses, edit /etc/apparmor.d/libvirt/TEMPLATE and the other similar profiles in /etc/apparmor.d/libvirt/ and add:

  /run/shm/lttng-ust-wait-5 rw,

Then run apparmor_parser --replace $(ls -1 /etc/apparmor.d/libvirt/libvirt* | grep -v files)

This does allow for cross-domain contamination. If you want to deny these accesses instead you can prepend "deny" to that rule above; I don't know if libvirt handles that gracefully or not, but it would prevent cross-domain contamination.

Thanks

@jdstrand

I'm running the latest ceph-docker/daemon image with the ceph package version 0.94.2-1trusty and see the same issue:

libust[5136/5462]: Error: Error opening shm /lttng-ust-wait-5-0 (in get_wait_shm() at lttng-ust-comm.c:886)
libust[5136/5461]: Error: Error opening shm /lttng-ust-wait-5 (in get_wait_shm() at lttng-ust-comm.c:886)

Is it possible to somehow get the fix that was made in 0.93-0ubuntu6 over here as well?

Thanks

I'm affected too by the "log flooding" issue, although I can start VMs.

[4220163.899438] type=1400 audit(1447230173.207:7763726): apparmor="DENIED" operation="open" profile="libvirt-a9c8bb9b-f2cc-4e4f-b7b1-c6152d8029c4" name="/run/shm/lttng-ust-wait-5" pid=69948 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=111 ouid=0

I'm running Ubuntu 14.04.3 with cloud and ceph repositories.

ceph 0.94.3-1trusty
libvirt0 1.2.12-0ubuntu14.1~cloud0

It looks like this bug has regressed due to the path of lttng-ust-wait-5 path changing to the following:

/run/shm/lttng-ust-wait-5

Would someoone be kind enough to release a fix for this?

Issue still exists in 0.94.5-1trusty (hammer). Will this be ever fixed in hammer?

Reopening since this is not fixed in either ceph or libvirt to my knowledge. Package versions referenced here still have the issue.

The bug was fixed in vivid (and later). Which libvirt version are you using?

It sounds like we need to SRU this to trusty.

Hi All

We had the same issue, but in our end it was misconfiguration of the key.
Make sure that the key you see in trace log is indeed the key you have in /etc/ceph/ceph.client.cinder.keying, if not try to fix in /etc/libvirt/secrets/<your uuid>, and reload with virsh secret define.
If it configured OK, make sure that it also configured on ceph cluster (ceph auth list).

We're using libvirt 1.2.12-0ubuntu13~cloud0.

Patz: There is noting in syslog about a key. I don't believe this bug has anything to do with a key.

Serge we (Matt Fischer and myself) are using UCA Kilo with Trusty.

@serge this is a different path in Hammer that needs also to have a fix similar to 1432644 so ANOTHER lttng issue.

And since that was self-referential, maybe we just need a brand new bug.

So Mfischer said "reopening" I think the bug recurred in a slightly different way. So maybe we need a new bug.... either way we'd like the fix.

adding /run/shm/lttng-ust-wait-5 rw, to /etc/apparmor.d/abstractions/libvirt-qemu is the fix.

Note that adding that entry may allow virtual machines an unexpected and unwelcome amount of influence over the host system. If you just want the errors silenced, use 'deny /run/shm/lttng-ust-wait-5 rw,' instead. If you actually want lttng to function, then feel free to continue using the allow rule but be sure you know why you want it and what it allows guests to do.

Thanks

FYI ceph v0.94.6 will load LTTng-UST only when specifically configured. This should avoid SELinux / AppArmor denials in most cases. See http://tracker.ceph.com/issues/13274

Ken, that's great: denying lttng in the profile just to silence the logs is certainly unfortunate for the people who want to use lttng to measure and inspect their VMs as the reason why lttng doesn't work is impossible to discover.

Thanks

Marking ceph task as invalid, packages in Ubuntu don't enable this feature unlike upstream.

Wily is going to be EOL in less than two months. Could we please have a
minimal xml for reproduction, or even better verification of the package
in wily-proposed? I would simply recommend closing this bug unsolved,
except the fix is wrapped up with several others which were already verified.

This was reopened because of a regression. That regression was handled in Bug #1529319, so I'm resetting this bug to its previous status.