Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1147705 - SELinux is preventing sh from 'execute' accesses on the file /usr/sbin/unbound-control.
Summary: SELinux is preventing sh from 'execute' accesses on the file /usr/sbin/unboun...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:21f030a0b9f0816e100016680fc...
: 1147608 1147704 1159347 1167134 (view as bug list)
Depends On:
Blocks: dnssec Default_Local_DNS_Resolver
TreeView+ depends on / blocked
 
Reported: 2014-09-29 22:40 UTC by Christian Stadelmann
Modified: 2019-04-29 09:18 UTC (History)
20 users (show)

Fixed In Version: selinux-policy-3.13.1-105.13.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-30 01:09:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch to fix the file descriptor leak (deleted)
2015-01-05 14:15 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff

Description Christian Stadelmann 2014-09-29 22:40:59 UTC
Description of problem:
SELinux is preventing sh from 'execute' accesses on the file /usr/sbin/unbound-control.

*****  Plugin catchall (100. confidence) suggests   **************************

If sie denken, dass es sh standardmässig erlaubt sein sollte, execute Zugriff auf unbound-control file zu erhalten.
Then sie sollten dies als Fehler melden.
Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen.
Do
zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen:
# grep sh /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:dnssec_trigger_t:s0
Target Context                system_u:object_r:named_exec_t:s0
Target Objects                /usr/sbin/unbound-control [ file ]
Source                        sh
Source Path                   sh
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           unbound-1.4.22-5.fc21.x86_64
Policy RPM                    selinux-policy-3.13.1-82.fc21.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.16.3-302.fc21.x86_64 #1 SMP Fri
                              Sep 26 14:27:20 UTC 2014 x86_64 x86_64
Alert Count                   2
First Seen                    2014-09-29 20:49:36 CEST
Last Seen                     2014-09-29 20:49:37 CEST
Local ID                      10f40912-a6cd-42c1-8d14-c661d1c5e257

Raw Audit Messages
type=AVC msg=audit(1412016577.526:394): avc:  denied  { execute } for  pid=1642 comm="sh" name="unbound-control" dev="dm-0" ino=260590 scontext=system_u:system_r:dnssec_trigger_t:s0 tcontext=system_u:object_r:named_exec_t:s0 tclass=file permissive=0


Hash: sh,dnssec_trigger_t,named_exec_t,file,execute

Version-Release number of selected component:
selinux-policy-3.13.1-82.fc21.noarch

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.3-302.fc21.x86_64
type:           libreport

Comment 1 Miroslav Grepl 2014-10-13 14:05:21 UTC
*** Bug 1147704 has been marked as a duplicate of this bug. ***

Comment 2 Miroslav Grepl 2014-10-13 14:05:42 UTC
*** Bug 1147608 has been marked as a duplicate of this bug. ***

Comment 3 Miroslav Grepl 2014-10-13 14:07:37 UTC
commit 5dee492b238b1882272261e7ffd23a515d38689d
Author: Miroslav Grepl <mgrepl>
Date:   Mon Oct 13 16:06:24 2014 +0200

    Allow dnssec_trigger_t to execute unbound-control in own domain

Add to rawhide/f21/f20.

Comment 4 Fedora Update System 2014-10-14 11:18:54 UTC
selinux-policy-3.13.1-86.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-86.fc21

Comment 5 Fedora Update System 2014-10-16 02:00:43 UTC
Package selinux-policy-3.13.1-86.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-86.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12863/selinux-policy-3.13.1-86.fc21
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2014-10-22 07:50:16 UTC
selinux-policy-3.13.1-88.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-88.fc21

Comment 7 Fedora Update System 2014-10-28 21:49:54 UTC
selinux-policy-3.13.1-90.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Laurent Rineau 2014-10-29 11:16:30 UTC
Note that, although they were both closed as duplicates of this bug, the bug #1158117 is about Fedora 20, and the bug #1147608 is about Rawhide.

Comment 9 Kevin Fenzi 2014-11-02 02:01:18 UTC
Description of problem:
Just using dnssec-trigger. 

Version-Release number of selected component:
selinux-policy-3.13.1-89.fc22.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.18.0-0.rc2.git3.1.fc22.x86_64
type:           libreport

Comment 10 Kevin Fenzi 2014-11-02 02:02:13 UTC
Yeah, please fix also rawhide/f20. ;)

Comment 11 Tomáš Hozza 2014-11-03 08:01:32 UTC
Description of problem:
I don't know what triggers this, however I think unbound-control should NOT touch /run/dnssec-trigger/lock

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.16.6-203.fc20.x86_64
type:           libreport

Comment 12 Miroslav Grepl 2014-11-03 11:20:02 UTC
Tomas,
what is the current issue?

Comment 13 Tomáš Hozza 2014-11-03 11:33:43 UTC
I think ABRT messed things up.

SELinux is preventing /usr/sbin/unbound-control from write access on the file .

*****  Plugin leaks (86.2 confidence) suggests   *****************************

If you want to ignore unbound-control trying to write access the  file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/sbin/unbound-control /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (14.7 confidence) suggests   **************************

If you believe that unbound-control should be allowed write access on the  file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep unbound-control /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:named_t:s0
Target Context                system_u:object_r:dnssec_trigger_var_run_t:s0
Target Objects                 [ file ]
Source                        unbound-control
Source Path                   /usr/sbin/unbound-control
Port                          <Unknown>
Host                          thozza-pc
Source RPM Packages           unbound-1.4.22-5.fc20.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-192.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     thozza-pc
Platform                      Linux thozza-pc 3.16.6-203.fc20.x86_64 #1 SMP Sat
                              Oct 25 12:44:32 UTC 2014 x86_64 x86_64
Alert Count                   781
First Seen                    2014-10-24 18:25:03 CEST
Last Seen                     2014-11-03 12:27:47 CET
Local ID                      d6663554-e5b2-4fd0-9d4a-aee1171524e1

Raw Audit Messages
type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 scontext=system_u:system_r:named_t:s0 tcontext=system_u:object_r:dnssec_trigger_var_run_t:s0 tclass=file permissive=0


type=SYSCALL msg=audit(1415014067.263:706): arch=x86_64 syscall=execve success=yes exit=0 a0=1166740 a1=11687b0 a2=e06d00 a3=0 items=0 ppid=19075 pid=19110 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=unbound-control exe=/usr/sbin/unbound-control subj=system_u:system_r:named_t:s0 key=(null)

Hash: unbound-control,named_t,dnssec_trigger_var_run_t,file,write

however I wanted to file an unbound bug... I think unbound-control should not touch the file it tries to.

Comment 14 Lukas Vrabec 2014-11-03 11:42:43 UTC
*** Bug 1159347 has been marked as a duplicate of this bug. ***

Comment 15 Lukas Vrabec 2014-11-07 21:01:57 UTC
I added guys from unbound,

Guys what do you think about this AVC? 

Thank you for help!

Comment 16 pjp 2014-11-08 15:17:05 UTC
I've seen this message before on F20. It's seems like a glitch in SELinux policy, which prevents unbound-control from writing to /run/dnssec-trigger/lock.

---
type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 
---


The log message suggests overriding the policy by

---
If you want to ignore unbound-control trying to write access the  file, because you believe it should not need this access. Then you should report this as a bug. You can generate a local policy module to dontaudit this access. Do

# grep /usr/sbin/unbound-control /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp
---

It seems to fix the annoying abrt popup.

Comment 17 Tomáš Hozza 2014-11-10 08:09:42 UTC
(In reply to pjp from comment #16)
> I've seen this message before on F20. It's seems like a glitch in SELinux
> policy, which prevents unbound-control from writing to
> /run/dnssec-trigger/lock.

Hi PJP.

I don't see any reason why should unbound-control touch /run/dnssec-trigger/lock. This needs more investigation on unbound side!

Comment 18 Miroslav Grepl 2014-11-10 10:40:00 UTC
Well it looks like a leak from dnssec_trigger.

type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for  pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs" ino=21425 

on EXEC.

Comment 19 Charles R. Anderson 2014-11-16 01:26:55 UTC
Description of problem:
After applying updates, rebooting, and logging in this SELinux alert appeared.  I am using dnssec-trigger/unbound.

Additional info:
reporter:       libreport-2.2.3
hashmarkername: setroubleshoot
kernel:         3.17.2-200.fc20.x86_64
type:           libreport

Comment 20 Lukas Vrabec 2014-11-24 10:42:37 UTC
*** Bug 1167134 has been marked as a duplicate of this bug. ***

Comment 21 Pavel Šimerda (pavlix) 2014-11-24 11:45:56 UTC
(In reply to Miroslav Grepl from comment #18)
> Well it looks like a leak from dnssec_trigger.

More specifically dnssec-trigger-script written in Python.

> type=AVC msg=audit(1415014067.263:706): avc:  denied  { write } for 
> pid=19110 comm="unbound-control" path="/run/dnssec-trigger/lock" dev="tmpfs"
> ino=21425 
> 
> on EXEC.

Erm... this looks like the way to go:

diff --git a/dnssec-trigger-script.in b/dnssec-trigger-script.in
index 70066cb..a0aab2e 100644
--- a/dnssec-trigger-script.in
+++ b/dnssec-trigger-script.in
@@ -10,6 +10,10 @@ import os, sys, fcntl, shutil, glob, subprocess
 import logging, logging.handlers
 import socket, struct
 
+# Python compatibility stuff
+if not hasattr(os, "O_CLOEXEC"):
+    os.O_CLOEXEC = 0x80000
+
 DEVNULL = open("/dev/null", "wb")
 
 log = logging.getLogger()
@@ -33,7 +37,7 @@ class Lock:
         dirname = os.path.dirname(self.path)
         if not os.path.exists(dirname):
             os.makedirs(dirname)
-        self.lock = open(self.path, "w")
+        self.lock = os.open(self.path, os.O_WRONLY|os.O_CLOEXEC)
 
     def __enter__(self):
         fcntl.lockf(self.lock, fcntl.LOCK_EX)

Comment 22 William Brown 2014-11-24 21:23:46 UTC
Description of problem:
Joined wireless network with staff_u user. 

Version-Release number of selected component:
selinux-policy-3.13.1-92.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.3-300.fc21.x86_64
type:           libreport

Comment 23 Brian Vaughan 2014-12-11 19:19:45 UTC
Description of problem:
I installed and enabled unbound and dnssec-trigger, rebooted, then connected to OpenVPN via NetworkManager.

Version-Release number of selected component:
selinux-policy-3.13.1-99.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.4-301.fc21.x86_64
type:           libreport

Comment 24 Brian Vaughan 2014-12-14 05:29:32 UTC
Description of problem:
1. I just rebooted, after installing a new kernel.
2. Before the reboot, using nm-connection-editor, I had set NetworkManager to connect to my VPN after connecting to the local WiFi.

Version-Release number of selected component:
selinux-policy-3.13.1-99.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.6-300.fc21.x86_64
type:           libreport

Comment 25 Andrew Aylett 2014-12-30 23:35:43 UTC
Description of problem:
Happens when resuming from sleep.

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.7-300.fc21.x86_64
type:           libreport

Comment 26 Charles R. Anderson 2015-01-05 13:37:44 UTC
Description of problem:
Nothing, it just popped up by itself.  dnssec-trigger/unbound is running.  I did recently edit /etc/unbound/unbound.conf to set verbosity=1 and systemctl restart unbound.

Version-Release number of selected component:
selinux-policy-3.13.1-103.fc21.noarch

Additional info:
reporter:       libreport-2.3.0
hashmarkername: setroubleshoot
kernel:         3.17.7-300.fc21.x86_64
type:           libreport

Comment 27 Pavel Šimerda (pavlix) 2015-01-05 14:15:27 UTC
Created attachment 976463 [details]
patch to fix the file descriptor leak

Comment 28 Pavel Šimerda (pavlix) 2015-01-05 14:17:05 UTC
Will be sending a couple of patches including this one that I had to fix up yesterday.

Comment 29 Pavel Šimerda (pavlix) 2015-01-19 11:49:01 UTC
*** Bug 1183159 has been marked as a duplicate of this bug. ***

Comment 30 John Heidemann 2015-01-19 17:16:52 UTC
Wrt bug 1183159: I didn't recongize it as a duplicate because the subject line here shows a different problem.

But bug 1147705 is NEEDINFO, can someone restate what info you would like?

Comment 31 Pavel Šimerda (pavlix) 2015-01-21 15:38:31 UTC
(In reply to John Heidemann from comment #30)
> Wrt bug 1183159: I didn't recongize it as a duplicate because the subject
> line here shows a different problem.

Thanks, it indeed looks different. But apparently many comments refer to the lock issue which is now fixed upstream as well as in some update

> But bug 1147705 is NEEDINFO, can someone restate what info you would like?

I guess the requested info is on the solution. Closing the needinfo now because we need to reexamine carefully. 

(In reply to Kevin Fenzi from comment #10)
> Yeah, please fix also rawhide/f20. ;)

So what's the current status of comment #3? Is it in all Fedora branches? Reassigning to selinux-policy for now.

If anyone is in doubt regarding dnssec-trigger, many issue have been fixed but an update for some of them is yet to be issued. You can try -17 (currently the latest) build from koji.

Comment 32 Kevin Fenzi 2015-02-02 14:11:05 UTC
I no longer see this here. There's another denial, but can open a new bug for it: 

SELinux is preventing /usr/sbin/dnssec-triggerd from write access on the directory /etc.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow dnssec-triggerd to have write access on the etc directory
Then you need to change the label on /etc
Do
# semanage fcontext -a -t FILE_TYPE '/etc'
where FILE_TYPE is one of the following: dnssec_trigger_var_run_t, net_conf_t, var_run_t. 
Then execute: 
restorecon -v '/etc'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that dnssec-triggerd should be allowed write access on the etc directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep dnssec-triggerd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:dnssec_trigger_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc [ dir ]
Source                        dnssec-triggerd
Source Path                   /usr/sbin/dnssec-triggerd
Port                          <Unknown>
Host                          voldemort.scrye.com
Source RPM Packages           dnssec-trigger-0.12-18.fc22.x86_64
Target RPM Packages           filesystem-3.2-32.fc22.x86_64
Policy RPM                    selinux-policy-3.13.1-106.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     voldemort.scrye.com
Platform                      Linux voldemort.scrye.com
                              3.19.0-0.rc6.git3.1.fc22.x86_64 #1 SMP Fri Jan 30
                              15:54:41 UTC 2015 x86_64 x86_64
Alert Count                   49
First Seen                    2015-01-20 07:12:06 MST
Last Seen                     2015-02-02 06:54:14 MST
Local ID                      371126d2-dc55-4451-9439-f1abe7abf639

Raw Audit Messages
type=AVC msg=audit(1422885254.181:9599): avc:  denied  { write } for  pid=8793 comm="dnssec-triggerd" name="etc" dev="dm-2" ino=1697281 scontext=system_u:system_r:dnssec_trigger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0


type=SYSCALL msg=audit(1422885254.181:9599): arch=x86_64 syscall=open success=no exit=EACCES a0=7fe650fcf480 a1=241 a2=1b6 a3=4000 items=0 ppid=1 pid=8793 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=dnssec-triggerd exe=/usr/sbin/dnssec-triggerd subj=system_u:system_r:dnssec_trigger_t:s0 key=(null)

Hash: dnssec-triggerd,dnssec_trigger_t,etc_t,dir,write

Comment 33 Pavel Šimerda (pavlix) 2015-02-03 12:33:49 UTC
(In reply to Kevin Fenzi from comment #32)
> If you want to allow dnssec-triggerd to have write access on the etc
> directory

This is the result of fixing bug #1165746 where dnssec-trigger originally rewrote the /etc/resolv.conf contents whereas other tools created a new file in /etc/ and moved it over to /etc/resolv.conf. Now dnssec-triggerd works like other tools.

Do you want to open a new bug?

Comment 34 Kevin Fenzi 2015-02-03 17:55:17 UTC
I can if I see it again. As far as I am concerned this bug is fixed.

Comment 35 Moez Roy 2015-02-16 01:50:18 UTC
Can you send an updated build to F20 Updates testing? Or are you waiting for SELinux to be fixed?

Comment 37 Miroslav Grepl 2015-02-16 15:46:09 UTC
I believe this is only for F21, right?

Comment 38 Moez Roy 2015-02-16 19:44:43 UTC
(In reply to Miroslav Grepl from comment #37)
> I believe this is only for F21, right?

And F20.

Comment 39 Pavel Šimerda (pavlix) 2015-02-16 20:01:14 UTC
(In reply to Moez Roy from comment #38)
> (In reply to Miroslav Grepl from comment #37)
> > I believe this is only for F21, right?
> 
> And F20.

The package is always built for all >=F20 branches. So I would prefer if we could have the policy for all those versions as well, otherwise we'd need to abandon the practice which comes from the fact that the whole dnssec-trigger thing was experimental and we supported experimenting with it since F20.

I recommend that the policy is ready on >=F20 and then the bug is closed.

Comment 40 Lukas Vrabec 2015-02-25 19:55:28 UTC
agree I add fixes also for F20 branch

Comment 41 Tomáš Hozza 2015-04-09 09:48:35 UTC
Any update on this? Thanks!

Comment 42 Lukas Vrabec 2015-04-09 19:52:09 UTC
commit 06005bc0ac9370f93ba99e44d478e9930f3896c1
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 21:06:09 2015 +0200

    Allow dnssec_trigger_t to stream connect to networkmanager.

commit 2c3a0d6d02474851e2ffd711ae8fd5176003624e
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 19:35:47 2015 +0200

    Allow dnssec_trigger_t to create resolv files labeled as net_conf_t

commit cfb2997e16f7106c916c903d4aac2aa9102ba7bf
Author: Lukas Vrabec <lvrabec>
Date:   Thu Apr 9 17:57:43 2015 +0200

    Label new dnssec-trigger files.

Comment 43 Fedora Update System 2015-04-16 21:30:18 UTC
selinux-policy-3.13.1-105.13.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-105.13.fc21

Comment 44 Fedora Update System 2015-04-18 09:40:06 UTC
Package selinux-policy-3.13.1-105.13.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-105.13.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-6316/selinux-policy-3.13.1-105.13.fc21
then log in and leave karma (feedback).

Comment 45 Fedora Update System 2015-04-22 22:44:11 UTC
selinux-policy-3.13.1-105.13.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 46 Laurent Rineau 2015-05-11 07:48:14 UTC
The AVC is still triggers on Fedora 20. Do you plan to submit an update for it?

Comment 47 Laurent Rineau 2015-06-08 12:37:19 UTC
The AVC is still triggered on Fedora 20. Can the update be submitted before the end-of-life of F20?

Comment 48 Fedora End Of Life 2015-06-30 01:09:41 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.