186601 - Remove localconfig and data/ from the Bugzilla webroot

Status: NEW

(Bugzilla :: Installation & Upgrading, enhancement)

Description

[Sergey Lipnevich]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021209
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021209

My message to the newsgroup of 10/07/02:

For the purpose of having multuple Bugzilla repositories on the same system
reusing same source code, I adjusted Bugzilla to use localconfig and data/
information located one level *above* Bugzila home, like this:

/projectA/config/bugzilla/localconfig
/projectA/config/bugzilla/data/...
/projectA/config/bugzilla/cgi -> symlink to /usr/share/bugzilla where
                                  the actual code is
/projectB/config/bugzilla/localconfig
/projectB/config/bugzilla/data/...
/projectB/config/bugzilla/cgi -> symlink to /usr/share/bugzilla

This way, globals.pl located localconfig and data/ and sets several
global variables to point at relevant files/directories. All other
Bugzilla modules are reusing these variables instead of having them
hard-coded. Things like database info and data/params are then different
for each repository, while source code is the same.

I have also parameterized all paths that I could find.

Reproducible: Always

Steps to Reproduce:




I'm attaching the patch which is NOT ready for inclusion into Bugzilla because
it breaks many rules and all previous installations. But in order to move
forward I need feedback as to whether Bugzilla needs this change.

Comment 1

[Sergey Lipnevich]

Attachment: bugzilla-paths.patch

This is a complete diff against Bugzilla tip of 2002-12-19 (2.17.2 pretty much)

Comment 2

[Sergey Lipnevich]

* CGI.pl
  Escape quote to make EMACS happy
  ReplaceScriptName is used to take current script's full (physical) path, and
    change the basename to something else, in this case `processmail' script
* attachment.cgi
  ReplaceScriptName for processmail script
* checksetup.pl
  Use all parameterized paths
  `which` doesn't work when checksetup is run using full path (explained later),
    so it's better to check defaults first
  "DROP TABLE" replaced with "delete all data and notify that the table must be
    dropped", because mysql account shouldn't have "drop table" permissions
* collectstats.pl, defparams.cgi, duplicates.cgi, editcomponents.cgi
* editkeywords.cgi, editmilestones.cgi, editproducts.cgi, editversions.cgi
* processmail
  Parameterized paths
* doeditparams.cgi, importxml.pl, move.pl, post_bug.cgi, process_bug.cgi
* contrib/bug_email.pl, contrib/bugzilla_email_append.pl
  Parameterized paths
  ReplaceScriptName for syncshadowdb or processmail scripts
* globals.pl
  A small "mis-diff ;-) because earlier version of the patch was implemented in
    this file
  Wrong diff for contenttypes (sorry about this mess)
  Parameterized paths mainly
* quicksearch.html, quicksearchhack.html, template/en/default/sidebar.xul.tmpl
  inclusion of localconfig.js from parent dir ../ which probably doesn't work
* reports.cgi
  Removed a parameter $dir "destination directory" because it's always the same
  $graph_dir parameterized
  Parameterized paths
* showdependencygraph.cgi
  Parameterized paths
  Needs another small module which would simply load an image generated in
    "now hidden" data/ folder and send it straight through
  Doesn't work "as is" right now
* Bugzilla/Config.pm
  The meat of changes: sets all the path-parameters
  Calculation of a directory where `localconfig' is, is complicated by the fact
    that Perl is too eager to dereference all symlinks
  In other languages (I also dealt with similar change to other web-based
    products) I was able to just "get parent folder" and it wasn't dereferenced
  $contenttypes is fixed now but it used to be broken in Bugzilla 2.17, so I
    made the correction myself and didn't change it after Bugzilla was fixed
  Error messages have sometimes been changed to a more "amorphous" text because
    they might appear in the actual output to a malicious user who doesn't have
    to know where the absolute file locations

Comment 3

[Dave Miller [:justdave]]

errr...  "Reassign to default"  :)  (knew I was forgetting something)

Comment 4

[Dave Miller [:justdave]]

Comment on attachment 110035 [details] [diff] [review]
bugzilla-paths.patch

per reporter, this is not ready for inclusion in Bugzilla, so marking as such. 
This is severely bitrotted by now anyway.  The data directory can already be
moved by editing one line in Bugzilla/Config.pm now (as can the template
directory and the location of the localconfig file).

There's still a fair bit to be done though.  (We need this to get Debian to
stop patching us for their package ;)

Comment 5

[Dave Miller [:justdave]]

enhancements without current patches are being pushed to 2.20

Comment 6

[:glob ✱]

removing localconfig and data from webroot is good from a secuirity point of
view when you're using a web server that doesn't honour the .htaccess rules (eg
iis, some apache configs).

it took me less than a minute of googling to locate a bugzilla install with a
world readable localconfig and data/params (running on apache, with
$create_htaccess = 1).

Comment 7

[Dave Miller [:justdave]]

localconfig and data can already be moved.  The main remaining problem is
getting the "displayed by webserver" stuff (html/js/css/gif/etc) separated from
the executable (cgi) stuff.  (Oh, and getting an installer or something to let
you choose where they all go at install time, instead of having to move the
files yourself and changing the line in Config.pm to tell where they are).

Comment 8

[:glob ✱]

> localconfig and data can already be moved

yup, however i feel they should be moved by default.

> getting the "displayed by webserver" stuff (html/js/css/gif/etc)
> separated from the executable (cgi) stuff

i don't think that cgi's should be separated from static pages, i just expect
files that are not directly accessable externally (localconfig, data/,
templates, etc) be relocated outside of the wwwroot.

main problem is implementing this without breaking existing installs, however i
suspect bug 44659 covers this.

Comment 9

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.