177850 - checksetup fails if the user does not have read permission to the whole bugzilla path

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect, P3)

Description

[Jussi Sirpoma]

When I was installing bugzilla to a site where the path to bugzilla was:

/data/www/customers/xyz/public_html/bugzilla

After finddepth had reported the error, cwd was /data/www/customers

I added a chdir("/data/www/customers/xyz/public_html/bugzilla") after the
finddepth and changed COMPILE_DIR to point to full path. After these changes I
managed to get checksetup through.

Error message from unmodified checksetup:

Removing existing compiled templates ...
[Fri Nov  1 05:48:28 2002] checksetup.pl: Can't stat data/template: No such file
or directory
Content-type: text/html

<H1>Software error:</H1>
<PRE>mkdir data: Permission denied at
/data/www/customers/xyz/local/share/perl/5.6.1/Template/Provider.pm line 368
</PRE>
<P>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

[Fri Nov  1 05:48:28 2002] checksetup.pl: mkdir data: Permission denied at
/data/www/customers/xyz/local/share/perl/5.6.1/Template/Provider.pm line 368

Comment 1

[Bradley Baetz (:bbaetz)]

Waht is the current working directory before finddepth is run?

Comment 2

[Jussi Sirpoma]

The current working directory before finddepth was
/data/www/customers/xyz/public_html/bugzilla

I used system("pwd") to print them (in case that has some side effects).

Comment 3

[Bradley Baetz (:bbaetz)]

hmm. Something is odd, here.

What perl version do you have? Waht vrsion of File::Find?

Comment 4

[Jussi Sirpoma]

The perl version is 5.6.1. I'm not that sure about File::Find since the file
does not specify a version.

After a bit of digging I found the real problem: Some of the directories below
bugzilla directory have only execute bit set for the bugzilla user and for some
reason File::Find stat's every directory in the path (checking for symlinks?).
When this fails it leaves the working directory to the incorrect value.

This installation is in a hosted site so I do not have control over the permissions.

Comment 5

[Bradley Baetz (:bbaetz)]

Hmmm.

I can stat a directory if only +x is set, though, plus I can't reprporduce this.
There is an opendir call, but that should be error-safe.

Theres a line in checksetup which does |local (^W) = 0;|. If you comment that
out, do you get any warnings from File::Find?

Comment 6

[Jussi Sirpoma]

With a fresh cvs checkout and these permissions I can reproduce the problem. The
next run after localconfig has been created results in the error message.

jussi@gandalf[~/tmp/mozilla/webtools] $ pwd
/home/jussi/tmp/mozilla/webtools
jussi@gandalf[~/tmp/mozilla/webtools] $ ll -d .
d--x------    4 jussi    jussi        4096 marras  4 15:35 ./
jussi@gandalf[~/tmp/mozilla/webtools] $ cd bugzilla
jussi@gandalf[~/tmp/mozilla/webtools/bugzilla] $ ll -d .
drwxrwxr-x   16 jussi    jussi        4096 marras  4 15:46 ./
jussi@gandalf[~/tmp/mozilla/webtools/bugzilla] $ ./checksetup.pl

It seems that File::Find uses Cwd::fastcwd which changes the directory and does
an opendir for the parent directories. The Cwd documentation warns about this
kind of a problem but I don't know what can be done to prevent it.

Comment 7

[Bradley Baetz (:bbaetz)]

Hmm, looking at code, that only happens for the finddepth case.

Maybe we could use File::Path::rmtree, and 'detect' errors by confirming that
the dir no  longer exists?

Comment 8

[Jussi Sirpoma]

Attachment: Fix using File::Path::rmtree

Here is a fix using rmtree. The getcwd call few lines further caused the error
also, so I changed it to normal cwd.

Comment 9

[Joel Peshkin]

I think it is safe to confirm this and target it for 2.18.  It is going to need
a fix in either code or documentation.  I hit it myself and found it annoying. 
It would be bad for someone who was setting up their first system.

Comment 10

[Dave Miller [:justdave]]

Comment on attachment 105581 [details] [diff] [review]
Fix using File::Path::rmtree

r= justdave

Ran into this myself trying to upgrade an old pre-template Bugzilla that is
maintained as a non-root user.

Tried out this patch, and it works.

Comment 11

[Dave Miller [:justdave]]

reassigning to patch author

Comment 12

[Dave Miller [:justdave]]

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.208; previous revision: 1.207
done