in reply to Proper and acceptable use of backticks in a modern Perl script

Did you read Taint mode? There's some criteria where taint is automatically enabled.

  • Comment on Re: Proper and acceptable use of backticks in a modern Perl script

Replies are listed 'Best First'.
Re^2: Proper and acceptable use of backticks in a modern Perl script
by Polyglot (Chaplain) on Sep 18, 2023 at 10:56 UTC
    Thank you for the response. No, I hadn't read that. Reading it now, however, I see that it points toward issues I do not have:

    1) An issue with either SETUID or SETGID, neither of which applies to my case. This is being run as an ordinary cgi script on the server, with no special permissions.

    2) An issue with the external command affecting something else external to the script. Not applicable to my use case either.

    Etc.

    So, what applies to my case is this:

    $arg, `true`;        # Insecure (although it isn't really)

    The parenthesized statement, the last in its list of examples, is what applies to me. What I am doing should not be a problem! But, I don't see in that file what I am supposed to do about this.

    ....WAIT....

    Then I found this: 

    On versions of Perl before 5.26, activating taint mode will also remov
+e the current directory (".") from the default value of @INC. Since v
+ersion 5.26, the current directory isn't included in @INC by default.

Cleaning Up Your Path

For "Insecure $ENV{PATH}" messages, you need to set $ENV{'PATH'} to a 
+known value, and each directory in the path must be absolute and non-
+writable by others than its owner and group. You may be surprised to 
+get this message even if the pathname to your executable is fully qua
+lified. This is not generated because you didn't supply a full path t
+o the program; instead, it's generated because you never set your PAT
+H environment variable, or you didn't set it to something that was sa
+fe. Because Perl can't guarantee that the executable in question isn'
+t itself going to turn around and execute some other program that is 
+dependent on your PATH, it makes sure you set the PATH.

    [download]

    ...and I added a line to my code:

    $ENV{'PATH'} = '/var/www/';

    ...and simple as that, the problem was solved. I guess I have heretofore been fortunate enough to work with versions of Perl before 5.26.

    Blessings,

    ~Polyglot~

[reply]
[d/l]
[select]
      $ENV{'PATH'} = '/var/www/';

      All relevant executables are in /var/www? I HIGHLY doubt that. A safe value for $ENV{'PATH'} is generally /bin:/usr/bin (which is also the default path set by the operating system, i.e. kernel and/or init). If you want to avoid any executable to be run without an giving its absolute path, set $ENV{'PATH'} to a non-existing or empty directory.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
        It won't matter what directory it is set to, as long as it is set. The script runs fine. I am giving the full path of the executable in the backticks, so it shouldn't matter. When an "anything goes" directory solves the problem, it shows the futility of the rule, in my opinion. I realize that people will downvote this like they did my other comment about setting the file to anything, but this is the reality of the situation. The script is not using this $ENV{PATH} variable for anything, so being forced to set it, when not using it, is no more secure than if I had not faced such a requirement.

        Blessings,

        ~Polyglot~

[reply]
[d/l]

In Section Seekers of Perl Wisdom