The local XML file './data/bugzilla-update.xml' cannot be created
Peskin, Eric
I was able to log in to the Bugzilla main page using my administrator account.
>From there, I set the parameters:
urlbase = https://10.193.37.91/bugzilla/
and cookiepath = /bugzilla/
Now when I go back to the main page, the following message appears in a red box at the top of the Bugzilla Main Page:
"The local XML file './data/bugzilla-update.xml' cannot be created. Please make
sure the web server can write in this directory and that you can access the
web. If you are behind a proxy, set the proxy_url parameter correctly."
This is strange, because:
1) I can access the web.
2) I am not behind a proxy.
3) The permissions are as follows:
drwxr-x--- 16 root apache 4096 Mar 31 10:46 /var/www/html/bugzilla/
drwxrwx--- 7 root apache 4096 Mar 31 14:11 /var/www/html/bugzilla/data
Here is some information about my system:
[root@koi-test data]# uname -a
Linux koi-test.vz30.nyumc.org 2.6.18-238.1.1.el5 #1 SMP Tue Jan 18 18:49:37 EST
2011 x86_64 x86_64 x86_64 GNU/Linux
[root@koi-test data]# cat /etc/redhat-release
Scientific Linux SL release 5.4 (Boron)
[root@koi-test data]# rpm -q httpd mysql mysql-server perl
httpd-2.2.3-43.sl5.3.x86_64
mysql-5.0.77-4.el5_5.4.x86_64
mysql-server-5.0.77-4.el5_5.4.x86_64
perl-5.8.8-32.el5_5.1.x86_64
Any help would be greatly appreciated.
------------------------------------------------------------
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is proprietary, confidential, and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure, or distribution is prohibited. If you have received this email in error please notify the sender by return email and delete the original message. Please note, the recipient should check this email and any attachments for the presence of viruses. The organization accepts no liability for any damage caused by any virus transmitted by this email.
=================================
Raghu Kumar C
~raghu
_______________________________________________
support-bugzilla mailing list
support-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-bugzilla
PLEASE put support-...@lists.mozilla.org in the To: field when you reply.
Tavant Technologies sponsors MBA's Mortgage Tech Conference, March 27-29, Hollywood, FL. See you there.
Any comments or statements made in this email are not necessarily those of Tavant Technologies.
The information transmitted is intended only for the person or entity to which it is addressed and may
contain confidential and/or privileged material. If you have received this in error, please contact the
sender and delete the material from any computer. All e-mails sent from or to Tavant Technologies
may be subject to our monitoring procedures.
Peskin, Eric
[root@koi-test ep599]# id apache
uid=48(apache) gid=48(apache) groups=48(apache) context=system_u:system_r:unconfined_t:SystemLow-SystemHigh
[root@koi-test ep599]# grep ^Group /etc/httpd/conf/httpd.conf
Group apache
[root@koi-test ep599]# grep webservergroup /var/www/html/bugzilla/localconfig
$webservergroup = 'apache';
[root@koi-test ep599]# ls -ld /var/www/html/bugzilla/data
drwxrwx--- 7 root apache 4096 Mar 31 15:18 /var/www/html/bugzilla/data
This is already as checksetup.pl left it.
Furthermore, just in case, I tried temporarily giving the world all permissions on the data directory (777, also known as a=rwx). It didn't help. I still got the same error.
Raghu Kumar C
~raghu
Peskin, Eric
[root@koi-test html]# ls -al /var/www/html/
total 24
drwxr-xr-x 3 root root 4096 Mar 31 10:45 .
drwxr-xr-x 6 root root 4096 Mar 31 10:16 ..
drwxr-x--- 16 root apache 4096 Mar 31 10:46 bugzilla
[root@koi-test html]#
rojanu
getsebool -a | grep http
> >> urlbase =https://10.193.37.91/bugzilla/
> >> support-bugzi...@lists.mozilla.org
> >>https://lists.mozilla.org/listinfo/support-bugzilla
> >> PLEASE put support-bugzi...@lists.mozilla.org in the To: field when you reply.
Peskin, Eric
[ep599@koi-test ~]$ /usr/sbin/getsebool -a | grep http
allow_httpd_anon_write --> off
allow_httpd_bugzilla_script_anon_write --> off
allow_httpd_cvs_script_anon_write --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_nagios_script_anon_write --> off
allow_httpd_prewikka_script_anon_write --> off
allow_httpd_squid_script_anon_write --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> on
httpd_disable_trans --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_read_user_content --> off
httpd_rotatelogs_disable_trans --> off
httpd_ssi_exec --> off
httpd_suexec_disable_trans --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_nfs --> off
[ep599@koi-test ~]$
I installed setroubleshoot. When I go to the home page of the bugzilla administrative account, it gives the information appended below. However, even if I issue the suggested command:
setsebool -P httpd_can_network_relay=1
It does not seem to change SELinux's behavior. It is still the case that accessing the home page of the Bugzilla administrative account just results in another copy of the message below. I may be seeing the same bug reported at http://www.centos.org/modules/newbb/viewtopic.php?topic_id=25791&forum=42. I do not see an answer to that bug. Does anyone know about it?
In the mean time, as a workaround, I temporarily put SELinux in Permissive mode. This allowed Bugzilla to download the XML file, and gets the red box off of the home page. Them I put SELinux back in Enforcing mode. So I am fine for now, but I suspect this will cause trouble again in the future. Any ideas?
Here is the message from setroubleshoot:
========================================================================
Summary
SELinux is preventing the http daemon from connecting to the itself or
the relay ports
Detailed Description
SELinux has denied the http daemon from connecting to itself or the
relay ports. An httpd script is trying to do a network connect to an
http/ftp port. If you did not setup httpd to network connections, this
could signal a intrusion attempt. Allowing Access
If you want httpd to connect to httpd/ftp ports you need to turn on
the httpd_can_network_relay boolean: "setsebool -P
httpd_can_network_relay=1"
The following command will allow this access:
setsebool -P httpd_can_network_relay=1
Additional Information
Source Context: system_u:system_r:httpd_sys_script_t
Target Context: system_u:object_r:http_port_t
Target Objects: None [ tcp_socket ]
Source: editparams.cgiSource
Path: /usr/bin/perlPort: 80
Host: koi-test.vz30.nyumc.org
Source RPM Packages: perl-5.8.8-32.el5_5.1
Target RPM Packages:
Policy RPM: selinux-policy-2.4.6-279.el5_5.2
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Permissive
Plugin Name: httpd_can_network_relay
Host Name: koi-test.vz30.nyumc.org
Platform: Linux koi-test.vz30.nyumc.org 2.6.18-238.1.1.el5 #1 SMP Tue Jan 18 18:49:37 EST 2011 x86_64 x86_64
Alert Count: 8
First Seen: Mon 04 Apr 2011 10:10:53 AM EDT
Last Seen: Mon 04 Apr 2011 10:55:54 AM EDT
Local ID: ad0b2268-9b0c-4d3e-963b-d9196f7f398b
Line Numbers:
Raw Audit Messages :
host=koi-test.vz30.nyumc.org type=AVC msg=audit(1301928954.395:36565):
avc: denied { name_connect } for pid=29939 comm="index.cgi" dest=80
scontext=system_u:system_r:httpd_sys_script_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
host=koi-test.vz30.nyumc.org type=SYSCALL
msg=audit(1301928954.395:36565): arch=c000003e syscall=42 success=no
exit=-115 a0=4 a1=21c41cb0 a2=10 a3=0 items=0 ppid=17089 pid=29939
auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) ses=4294967295 comm="index.cgi"
exe="/usr/bin/perl" subj=system_u:system_r:httpd_sys_script_t:s0
key=(null)
> _______________________________________________
> support-bugzilla mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put support-...@lists.mozilla.org in the To: field when you reply.
Max Kanat-Alexander
> In the mean time, as a workaround, I temporarily put SELinux in Permissive mode. This allowed Bugzilla to download the XML file, and gets the red box off of the home page. Them I put SELinux back in Enforcing mode. So I am fine for now, but I suspect this will cause trouble again in the future. Any ideas?
The problem is the SELinux context of your bugzilla directory. For
normal Apache SELinux contexts, Bugzilla needs to be installed into
/var/www/html -- in general, SELinux won't allow Apache to write very
many other places.
If it is there, then this should fix it:
restorecon -Rv /var/www/html/bugzilla
(Assuming that's where Bugzilla is installed.)
-Max
--
Max Kanat-Alexander
Chief Architect, Community Lead, and Release Manager
Bugzilla Project
http://www.bugzilla.org/
Clyde Jones
update site because of firewall issues. Make sure you can actually
ping the bugzilla update servers. The script doesn't differentiate
between write errors and the inability to contact the update server
> _______________________________________________
> support-bugzilla mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put support-...@lists.mozilla.org in the To: field when you reply.
>
--
We are what we think. All that we are arises with our thoughts. With
our thoughts, we make the world.
-Buddha
Peskin, Eric
It's fixed!
No, it was not file permissions.
No, it was not the firewall.
Yes, it was SELinux:
No, it was not labeling of files or directories for SELinux context.
No, it was not the httpd_can_network_relay boolean (as claimed by setroubleshoot)
It is the httpd_can_network_connect boolean of SELinux!
The fix: Set httpd_can_network_connect to "on"
The question: What are the security concerns with doing that?
A suggestion: Bugzilla should at least distinguish between the two cases of being unable to write the file versus being unable to fetch the file. The man page for LWP::UserAgent shows how to do that. Bugzilla could print different error messages for the two cases.
Note that in this case, even once I knew it was a connection issue, it was still hard to track. I could reach the web page in question from the same server running as the same user (apache). It seemed to only fail when running within Bugzilla. It turns out that this is because SELinux knows when something is running on behalf of the web server.
Even once I started looking at SELinux, it was hard to track because setroubleshoot was pointing to the wrong boolean.
Oh, well.
Thanks to everyone for the suggestions.
On Apr 5, 2011, at 3:20 PM, Clyde Jones wrote:
> I ran into this problem when our server could not contact the bugzilla
> update site because of firewall issues. Make sure you can actually
> ping the bugzilla update servers. The script doesn't differentiate
> between write errors and the inability to contact the update server
>
>
>
> On Mon, Apr 4, 2011 at 18:55, Max Kanat-Alexander <mka...@bugzilla.org> wrote:
>> On 04/04/2011 08:31 AM, Peskin, Eric wrote:
>>> In the mean time, as a workaround, I temporarily put SELinux in Permissive mode. This allowed Bugzilla to download the XML file, and gets the red box off of the home page. Them I put SELinux back in Enforcing mode. So I am fine for now, but I suspect this will cause trouble again in the future. Any ideas?
>>
>> The problem is the SELinux context of your bugzilla directory. For
>> normal Apache SELinux contexts, Bugzilla needs to be installed into
>> /var/www/html -- in general, SELinux won't allow Apache to write very
>> many other places.
>>
>> If it is there, then this should fix it:
>>
>> restorecon -Rv /var/www/html/bugzilla
>>
>> (Assuming that's where Bugzilla is installed.)
>>
>> -Max
>> --
>> Max Kanat-Alexander
>> Chief Architect, Community Lead, and Release Manager
>> Bugzilla Project
>> http://www.bugzilla.org/
>> _______________________________________________
>> support-bugzilla mailing list
>> support-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/support-bugzilla
>> PLEASE put support-...@lists.mozilla.org in the To: field when you reply.
>>
>
>
>
> --
> We are what we think. All that we are arises with our thoughts. With
> our thoughts, we make the world.
> -Buddha
> _______________________________________________
> support-bugzilla mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-bugzilla
> PLEASE put support-...@lists.mozilla.org in the To: field when you reply.
Max Kanat-Alexander
> A suggestion: Bugzilla should at least distinguish between the two cases of being unable to write the file versus being unable to fetch the file. The man page for LWP::UserAgent shows how to do that. Bugzilla could print different error messages for the two cases.
That'd be great. We'd love a patch.The process for getting a patch into
Bugzilla is described here:
http://wiki.mozilla.org/Bugzilla:Developers