netscape.public.mozilla.webtools</ULINK> newsgroup. Without your
discussions, insight, suggestions, and patches, this could never have happened.
</PARA>
</SECTION>
<SECTIONid="contributors">
<TITLE>Contributors</TITLE>
<PARA>
Thanks go to these people for significant contributions
to this documentation (in no particular order):
</PARA>
<PARA>
Zach Lipton (significant textual contributions),
Andrew Pearson,
Spencer Smith,
Eric Hanson,
Kevin Brannen,
</PARA>
</SECTION>
<SECTIONID="feedback">
<TITLE>Feedback</TITLE>
<PARA>
I welcome feedback on this document. Without your submissions and input,
this Guide cannot continue to exist. Please mail additions, comments, criticisms, etc.
to <EMAIL>barnboy@trilobyte.net</EMAIL>. Please send flames to
<EMAIL>devnull@localhost</EMAIL>
</PARA>
</SECTION>
</para>
<para>
Last but not least, all the members of the <ulink
url="news://news.mozilla.org/netscape/public/mozilla/webtools"> netscape.public.mozilla.webtools</ulink> newsgroup. Without your discussions, insight, suggestions, and patches, this could never have happened.
</para>
</section>
<SECTIONID="translations">
<TITLE>Translations</TITLE>
<PARA>
The Bugzilla Guide needs translators!
Please volunteer your translation into the language of your choice.
If you will translate this Guide, please notify the members of the mozilla-webtools mailing list at
<email>mozilla-webtools@mozilla.org</email>. Since The Bugzilla Guide is also hosted on the
Linux Documentation Project, you would also do well to notify
</PARA>
</SECTION>
<sectionid="contributors">
<title>Contributors</title>
<para>
Thanks go to these people for significant contributions to this
documentation (in no particular order):
</para>
<para>
Andrew Pearson, Spencer Smith, Eric Hanson, Kevin Brannen, Ron Teitelbaum
</para>
</section>
<sectionid="feedback">
<title>Feedback</title>
<para>
I welcome feedback on this document. Without your submissions
and input, this Guide cannot continue to exist. Please mail
additions, comments, criticisms, etc. to
<email>barnboy@trilobyte.net</email>. Please send flames to
<email>devnull@localhost</email>
</para>
</section>
<sectionid="translations">
<title>Translations</title>
<para>
The Bugzilla Guide needs translators! Please volunteer your
translation into the language of your choice. If you will
translate this Guide, please notify the members of the
mozilla-webtools mailing list at
<email>mozilla-webtools@mozilla.org</email>, and arrange with
Matt Barnson to check it into CVS.
</para>
</section>
<!-- conventions used here (didn't want to give it a chapter of its own) -->
&conventions;
</CHAPTER>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:upper
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:Bugzilla-Guide\.sgml
sgml-auto-insert-required-elements:t
sgml-balanced-tag-edit:t
sgml-exposed-tags:nil
sgml-general-insert-case:lower
sgml-indent-data:t
sgml-indent-step:2
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
sgml-doctype:"<!DOCTYPE chapter PUBLIC \"-//OASIS//DTD DocBook V4.1//EN\">"
The MySQL Privelege System</ULINK> until you can recite it from memory!</PARA>
<PARA>
At the very least, ensure you password the "mysql -u root" account and the "bugs" account, establish grant
table rights (consult the Keystone guide in Appendix C: The Bugzilla Database for some easy-to-use details)
that do not allow CREATE, DROP, RELOAD, SHUTDOWN, and PROCESS for user "bugs". I wrote up the Keystone
advice back when I knew far less about security than I do now : )
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>
Lock down /etc/inetd.conf. Heck, disable inet entirely on this box. It should only listen to
port 25 for Sendmail
</para>
</note>
<para>
Secure your installation.
<note>
<para>
These instructions must, of necessity, be somewhat vague
since Bugzilla runs on so many different platforms. If you
have refinements of these directions for specific platforms,
please submit them to <ulinkurl="mailto://mozilla-webtools@mozilla.org">mozilla-webtools@mozilla.org</ulink>
</para>
</note>
<orderedlist>
<listitem>
<para>
Ensure you are running at least MysQL version 3.22.32 or
newer. Earlier versions had notable security holes and
poorly secured default configuration choices.
</para>
</listitem>
<listitem>
<para><emphasis>There is no substitute for understanding the
tools on your system!</emphasis> Read <ulinkurl="http://www.mysql.com/documentation/mysql/bychapter/manual_Privilege_system.html"> The MySQL Privilege System</ulink> until you can recite it from memory!</para>
<para>
At the very least, ensure you password the "mysql -u root"
account and the "bugs" account, establish grant table
rights (consult the Keystone guide in Appendix C: The
Bugzilla Database for some easy-to-use details) that do
not allow CREATE, DROP, RELOAD, SHUTDOWN, and PROCESS for
user "bugs". I wrote up the Keystone advice back when I
knew far less about security than I do now : )
</para>
</listitem>
<listitem>
<para>
Lock down /etc/inetd.conf. Heck, disable inet entirely on
this box. It should only listen to port 25 for Sendmail
and port 80 for Apache.
</PARA>
</LISTITEM>
<LISTITEM>
<PARA>Do not run Apache as "nobody". This will require very lax permissions in your Bugzilla directories.
Run it, instead, as a user with a name, set via your httpd.conf file.</PARA>
</LISTITEM>
<LISTITEM>
<PARA>
Ensure you have adequate access controls for the $BUGZILLA_HOME/data/ and
$BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig and
$BUGZILLA_HOME/globals.pl files.
The localconfig file stores your "bugs" user password,
which would be terrible to have in the hands
of a criminal, while the "globals.pl" stores some default information regarding your
installation which could aid a system cracker.
In addition, some files under $BUGZILLA_HOME/data/ store sensitive information, and
$BUGZILLA_HOME/shadow/ stores bug information for faster retrieval. If you fail to secure
these directories and this file, you will expose bug information to those who may not
be allowed to see it.
</PARA>
<NOTE>
<PARA>
Bugzilla provides default .htaccess files to protect the most common Apache
installations. However, you should verify these are adequate according to the site-wide
security policy of your web server, and ensure that the .htaccess files are
allowed to "override" default permissions set in your Apache configuration files.
Covering Apache security is beyond the scope of this Guide; please consult the Apache
documentation for details.
</PARA>
<PARA>
If you are using a web server that does not support the .htaccess control method,
<EMPHASIS>you are at risk!</EMPHASIS> After installing, check to see if you can
view the file "localconfig" in your web browser (ergo:
http://bugzilla.mozilla.org/localconfig</ULINK>. If you can read the contents of this
file, your web server has not secured your bugzilla directory properly and you
must fix this problem before deploying Bugzilla. If, however, it gives you a
"Forbidden" error, then it probably respects the .htaccess conventions and you
are good to go.
</PARA>
</NOTE>
<PARA>
On Apache, you can use .htaccess files to protect access to these directories, as outlined
in <ULINKURL="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug 57161</ULINK> for the
localconfig file, and <ULINKURL="http://bugzilla.mozilla.org/show_bug.cgi?id=65572">
Bug 65572</ULINK> for adequate protection in your data/ and shadow/ directories.
</PARA>
<PARA>
Note the instructions which follow are Apache-specific. If you use IIS, Netscape, or other
non-Apache web servers, please consult your system documentation for how to secure these
files from being transmitted to curious users.
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/data directory.
<LITERALLAYOUT>
<Files comments>
allow from all
</Files>
deny from all
</LITERALLAYOUT>
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/ directory.
<LITERALLAYOUT>
<Files localconfig>
deny from all
</Files>
allow from all
</LITERALLAYOUT>
</PARA>
<PARA>
Place the following text into a file named ".htaccess", readable by your web server,
in your $BUGZILLA_HOME/shadow directory.
<LITERALLAYOUT>
deny from all
</LITERALLAYOUT>
</PARA>
</LISTITEM>
</ORDEREDLIST>
</PARA>
</SECTION>
</CHAPTER>
</para>
</listitem>
<listitem>
<para>
Do not run Apache as <quote>nobody</quote>. This will
require very lax permissions in your Bugzilla directories.
Run it, instead, as a user with a name, set via your
httpd.conf file.
<note>
<para>
<quote>nobody</quote> is a real user on UNIX systems.
Having a process run as user id <quote>nobody</quote>
is absolutely no protection against system crackers
versus using any other user account. As a general
security measure, I recommend you create unique user
ID's for each daemon running on your system and, if
possible, use "chroot" to jail that process away from
the rest of your system.
</para>
</note>
</para>
</listitem>
<listitem>
<para>
Ensure you have adequate access controls for the
$BUGZILLA_HOME/data/ and $BUGZILLA_HOME/shadow/
directories, as well as the $BUGZILLA_HOME/localconfig and
$BUGZILLA_HOME/globals.pl files. The localconfig file
stores your "bugs" user password, which would be terrible
to have in the hands of a criminal, while the "globals.pl"
stores some default information regarding your
installation which could aid a system cracker. In
addition, some files under $BUGZILLA_HOME/data/ store
sensitive information, and $BUGZILLA_HOME/shadow/ stores
bug information for faster retrieval. If you fail to
secure these directories and this file, you will expose
bug information to those who may not be allowed to see it.
</para>
<note>
<para>
Bugzilla provides default .htaccess files to protect the
most common Apache installations. However, you should
verify these are adequate according to the site-wide
security policy of your web server, and ensure that the
.htaccess files are allowed to "override" default
permissions set in your Apache configuration files.
Covering Apache security is beyond the scope of this
Guide; please consult the Apache documentation for
details.
</para>
<para>
If you are using a web server that does not support the
.htaccess control method, <emphasis>you are at
risk!</emphasis> After installing, check to see if
you can view the file "localconfig" in your web browser
(e.g.: <ulinkurl="http://bugzilla.mozilla.org/localconfig"> http://bugzilla.mozilla.org/localconfig</ulink>). If you can read the contents of this file, your web server has not secured your bugzilla directory properly and you must fix this problem before deploying Bugzilla. If, however, it gives you a "Forbidden" error, then it probably respects the .htaccess conventions and you are good to go.
</para>
</note>
<para>
On Apache, you can use .htaccess files to protect access
to these directories, as outlined in <ulinkurl="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug 57161</ulink> for the localconfig file, and <ulinkurl="http://bugzilla.mozilla.org/show_bug.cgi?id=65572"> Bug 65572</ulink> for adequate protection in your data/ and shadow/ directories.
</para>
<para>
Note the instructions which follow are Apache-specific.
If you use IIS, Netscape, or other non-Apache web servers,
please consult your system documentation for how to secure
these files from being transmitted to curious users.
</para>
<para>
Place the following text into a file named ".htaccess",
readable by your web server, in your $BUGZILLA_HOME/data
<entry><programlisting><sgmltagclass="starttag">para</sgmltag>Beginning and end of paragraph<sgmltagclass="endtag">para</sgmltag></programlisting></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
This documentation is maintained in DocBook 4.1.2 XML format.
Changes are best submitted as plain text or XML diffs, attached
If you are going to use IIS, if on Windows NT you must
be updated to at least Service Pack 4. Windows 2000
ships with a sufficient version of IIS.
</para>
</note>
</step>
<step>
<para>
Install <ulinkurl="http://www.activestate.com/">ActivePerl</ulink> for Windows. Check <ulinkurl="http://aspn.activestate.com/ASPN/Downloads/ActivePerl/">http://aspn.activestate.com/ASPN/Downloads/ActivePerl</ulink> for a current compiled binary.
</para>
<para>
Please also check the following links to fully understand the status
Your configuration file for MySQL <EMPHASIS>must</EMPHASIS> be named C:\MY.CNF.
</PARA>
</NOTE>
</PARA>
</STEP>
<STEP>
<PARA>
<note>
<para>
You can download MySQL for Windows NT from <ulink
url="http://www.mysql.com/">MySQL.com</ulink>. Some find it helpful to use the WinMySqlAdmin utility, included with the download, to set up the database.
and the CPAN Net::SMTP Perl module (available in .ppm).
Every option requires some hacking of the Perl scripts for Bugzilla
to make it work. The option here simply requires the least.
</PARA>
</NOTE>
<PARA>
Download NTsendmail, available from<ULINKURL="http://www.ntsendmail.com/">
www.ntsendmail.com</ULINK>. In order for it to work, you must set up some
new environment variables (detailed on the ntsendmail home page). Figuring
out where to put those variables is left as an exercise for the reader.
You must have a "real" mail server which allows you to relay off it
in your $ENV{"NTsendmail"} (which you should probably place in globals.pl)
</PARA>
<PARA>
Once downloaded and installed, modify all open(SENDMAIL) calls to open
"| c:\ntsendmail\ntsendmail -t" instead of "|/usr/lib/sendmail -t".
</PARA>
<NOTE>
<PARA>
We need someone to test this and make sure this works as advertised.
</PARA>
</NOTE>
</STEP>
<STEP>
<PARA>
Modify globals.pl and CGI.pl to remove the word "encrypt".
</PARA>
<NOTE>
<PARA>
I'm not sure this is all that is involved to remove crypt. Any
NT Bugzilla hackers want to pipe up?
</PARA>
</NOTE>
</STEP>
<STEP>
<PARA>
Change all references to "processmail" to "processmail.pl" in
all files, and rename "processmail" to "processmail.pl"
</PARA>
<NOTE>
<PARA>
I really think this may be a change we want to make for
</para>
</note>
<procedure>
<step>
<para>
Download NTsendmail, available from<ulink
url="http://www.ntsendmail.com/"> www.ntsendmail.com</ulink>. You must have a "real" mail server which allows you to relay off it in your $ENV{"NTsendmail"} (which you should probably place in globals.pl)
</para>
</step>
<step>
<para>Put ntsendmail.pm into your .\perl\lib directory.</para>
</step>
<step>
<para>Add to globals.pl:</para>
<programlisting>
# these settings configure the NTsendmail process
use NTsendmail;
$ENV{"NTsendmail"}="your.smtpserver.box";
$ENV{"NTsendmail_debug"}=1;
$ENV{"NTsendmail_max_tries"}=5;
</programlisting>
<note>
<para>
Some mention to also edit
<varname>$db_pass</varname> in
<filename>globals.pl</filename> to be your
<quote>bugs_password</quote>. Although this may get
you around some problem authenticating to your
database, since globals.pl is not normally
restricted by <filename>.htaccess</filename>, your
database password is exposed to whoever uses your
web server.
</para>
</note>
</step>
<step>
<para>
Find and comment out all occurences of
<quote><command>open(SENDMAIL</command></quote> in
your Bugzilla directory. Then replace them with:
<programlisting>
# new sendmail functionality
my $mail=new NTsendmail;
my $from="bugzilla\@your.machine.name.tld";
my $to=$login;
my $subject=$urlbase;
$mail->send($from,$to,$subject,$msg);
</programlisting>
</para>
<note>
<para>The code above needs testing as well to make sure it is correct.</para>
</note>
</step>
</procedure>
</step>
<step>
<para>
Change all references in all files from
<filename>processmail</filename> to
<filename>processmail.pl</filename>, and
rename <filename>processmail</filename> to
<filename>processmail.pl</filename>.
</para>
<note>
<para>
Many think this may be a change we want to make for
main-tree Bugzilla. It's painless for the UNIX folks,
and will make the Win32 people happier.
</PARA>
</NOTE>
</STEP>
<STEP>
<PARA>
Modify the path to perl on the first line (#!) of all files
to point to your Perl installation, and
add "perl" to the beginning of all Perl system calls that
use a perl script as an argument. This may take you a while.
There is a "setperl.pl" utility to speed part of this procedure,
available in the "Patches and Utilities" section of The Bugzilla Guide.
</PARA>
</STEP>
<STEP>
<PARA>
In processmail.pl, add "binmode(HANDLE)" before all read() calls.
This may not be necessary, but in some cases the read() under
Win32 doesn't count the EOL's without using a binary read().
</PARA>
</STEP>
</PROCEDURE>
</SECTION>
<SECTIONid="addlwintips">
<TITLE>Additional Windows Tips</TITLE>
<TIP>
<PARA>
</para>
</note>
<note>
<para>
Some people have suggested using the Net::SMTP Perl module instead of NTsendmail or the other options listed here. You can change processmail.pl to make this work.
<programlisting>
<![CDATA[
my $smtp = Net::SMTP->new('<NameofyourSMTPserver>'); #connect to SMTP server
$smtp->mail('<yourname>@<yousmptserver>');# use the sender's adress here
$smtp->to($tolist); # recipient's address
$smtp->data(); # Start the mail
$smtp->datasend($msg);
$smtp->dataend(); # Finish sending the mail
$smtp->quit; # Close the SMTP connection
$logstr = "$logstr; mail sent to $tolist $cclist";
}
]]>
</programlisting>
here is a test mail program for Net::SMTP:
<programlisting>
<
