in reply to Re^2: Using relative paths with taint mode
in thread Using relative paths with taint mode

So, I am getting the point that taint, and later versions of Perl are trying to make it difficult to use relative paths for modules!

You may put it like that. It turned out that too many people get it wrong and catch security holes, so making it difficult (but not impossible) gives people a chance to ponder over other approaches.

If a website has more than one environment, then you need a plan anyway (again, nothing to do with taint mode) how you deploy and maintain the files in your different environments. There are many solutions for that, but I'd go for something like this: 

/home/myusername/somewebsite/prod/cgi-bin
/home/myusername/somewebsite/prod/lib
/home/myusername/somewebsite/prod/templates

[download]
with the same subdirectories for dev and test. So each environment has its own base directory, but below that they all have the same structure. Then it is indeed possible to use FindBin to detect which environment you're actually in (assuming you don't run a persistent interpreter like mod_perl).

my ($prefix,$website,$environment,$basedir);
BEGIN {
   $prefix = '/home/myusername';
   $website = 'somewebsite';
   use FindBin qw($RealBin);
   if ($RealBin =~ m!$prefix/$website/(dev|test|prod)/cgi-bin!) {
      $environment = $1; # This is now untainted!
      $basedir = "$prefix/$website/$environment";
   }
   else die "Bad or no environment '$1'";
}
use lib "$basedir/lib";
my $tt = Template->new({INCLUDE_PATH => "$basedir/templates"});
...;

[download]

The BEGIN block is needed to do the necessary calculations during the compilation so that the directory is available when use lib is processed.

Other alternatives include setting the environment as an environment (sic!) variable in the corresponding section of the web server config. Environment variables are tainted, so again you need to validate/untaint them.

Replies are listed 'Best First'.
Re^4: Using relative paths with taint mode
by Bod (Parson) on Jun 20, 2021 at 15:47 UTC
    If a website has more than one environment, then you need a plan anyway (again, nothing to do with taint mode) how you deploy and maintain the files in your different environments. There are many solutions for that, but I'd go for something like this: 
    /home/myusername/somewebsite/prod/cgi-bin
/home/myusername/somewebsite/prod/lib
/home/myusername/somewebsite/prod/templates

    [download]

    That is pretty much what I have at present - except the contents of lib are hung directly off cgi-bin. So doing it that way doesn't mean changing things drastically which is a good thing.

    But I don't see how having the modules like this 

    /home/myusername/somewebsite/prod/lib/Site/HTML.pm

    [download]
    is anymore secure than having them like this 
    /home/myusername/somewebsite/prod/cgi-bin/Site/HTML.pm

    [download]
    as they are still accessible through HTTP as prod/ is the web root. Of course they can be made inaccessible either through putting an index.html file in there or through an .htaccess file.

[reply]
[d/l]
[select]
      as they are still accessible through HTTP as prod/ is the web root.

      Why is that so? Do you understand the purpose of "web root"? Please clean that up: neither cgi-bin nor lib are supposed to lie under the web root (nor are templates). Also, an index.html doesn't make anything inaccessible, it just gets served when a browser is pointed to the directory (in a typical configuration).

      I mean, of course you can fiddle with as many of .htaccess files as you like, but why not simply avoid the problem in the first place?

[reply]
        Why is that so?

        Because that's where it gets put on my shared hosting...

        When I add a domain in cPanel it adds this by default: 

        /home/myusername/domain/cgi-bin/

        [download]
        Where domain/ is the webroot.

        I modify it slightly cPanel so I get: 

         
/home/myusername/domain/prod/cgi-bin/
/home/myusername/domain/test/cgi-bin/
/home/myusername/domain/dev/cgi-bin/

        [download]
        Where:
        www.domain.com -> prod/
        test.domain.com -> test/
        dev.domain.com -> dev/

        Because that's the way cPanel does it, I hadn't considered that there was a better way!

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom