1136709 - checksetup.pl should warn if the current perl env ($^X) doesn't match /usr/bin/perl

Status: RESOLVED WONTFIX

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

Description

[Dylan Hardison [:dylan] (he/him)]

We should allow CGI users to run bugzilla under any perl they have in PATH. To do this we need to update the shebang lines to #!/usr/bin/env perl

There is a downside to this: you cannot pass arguments to perl this way. To preserve taint mode, we'll need to set PERL5OPT="-T". We can do this in the example apache config, and document it for users of other httpds. 

The upside to this is that users of CentOS 6 (and related) can install a non-system perl and get Bugzilla to use it.

Comment 1

[Frédéric Buclin]

Hum, I heard CentOS has env in /bin/env instead of /usr/bin/env. Is that true?

Comment 2

[Frédéric Buclin]

(In reply to Dylan William Hardison [:dylan] from comment #0)
> There is a downside to this: you cannot pass arguments to perl this way. To
> preserve taint mode, we'll need to set PERL5OPT="-T".

Is that true? AFAIK, you can write:

#!/usr/bin/env PERL5OPT=-T perl

No need to hack apache config.

Comment 3

[David Lawrence [:dkl]]

Good news is that it is in both /usr/bin/env and /bin/env on Centos6 and 7. Strange thing is, in 6 /usr/bin/env is a symlink to /bin/env. And in 7 it is just the same file in both places. Either way we should be OK.

dkl

Comment 4

[Frédéric Buclin]

(In reply to Frédéric Buclin from comment #2)
> Is that true? AFAIK, you can write:
> 
> #!/usr/bin/env PERL5OPT=-T perl

Ah no, this doesn't work. PERL5OPT=-T makes the script to load forever, with no error message. I had to manually kill the script.

How do you plan to enable the taint mode for non-CGI scripts such as checksetup.pl or whine.pl? They do not depend on Apache.

Comment 5

[:glob ✱]

we had a long discussion about this on irc.
unfortunately #!/usr/bin/env and taint mode doesn't mix, which is pretty much a show stopper for using /usr/bin/env.

what we decided was to augment checksetup so it displays a highly visible warning if $^X isn't /usr/bin/perl, with instructions to run a new contrib script which changes the #! lines (with the exact required invocation).

https://wiki.mozilla.org/Bugzilla:FAQ#My_perl_is_located_at_.2Fusr.2Flocal.2Fbin.2Fperl_and_not_.2Fusr.2Fbin.2Fperl._Is_there_an_easy_to_change_that_in_all_the_files_that_have_this_hard-coded.3F

this means most sites won't see a difference, however if a site wants to use a different perl they just need to run checksetup to be pointed in the right direction.

eg.
/usr/local/globs_uber_perl/bin/perl checksetup.pl

should direct the user to run something like:
./contrib/change-perl-executable /usr/local/globs_uber_perl/bin/perl

Comment 6

[Frédéric Buclin]

On Windows, this warning shouldn't be displayed at all, because the shebang line is ignored, and C:\Perl\... will never match /usr/bin/perl. :)

Comment 8

[Jochen Wiedmann]

(In reply to Frédéric Buclin from comment #6)

> On Windows, this warning shouldn't be displayed at all, because the shebang
> line is ignored, 

Actually, that's not true, depending on the value of

  ScriptInterpreterSource (Script|Registry-Strict)

Comment 9

[Dylan Hardison [:dylan] (he/him)]

As we move towards PSGI and away from mod_perl, we don't need to care so much about which perl is being used.