in reply to system call windows

It's safer to use the list version of system:

system('/sbin/start', '/skipinfo', qq{-proxy:"$proxy_domain"});

[download]

I usually prefer to be explicit as to which executable gets called (fully qualify the path rather than a relative path). And it's a good practice to check the exit code of the system call. You'll want to read the documentation for system and perlvar (paying attention to the description of $?).

How safe all this is really depends a lot on what type of environment you're running it in. The primary advantage to using the list version of system is that it avoids the shell, thus reducing the potential for interpolation or unwanted redirection, piping, or code injection.


Dave

Replies are listed 'Best First'.
Re^2: system call windows
by BrowserUk (Patriarch) on Mar 06, 2019 at 22:07 UTC
    It's safer to use the list version of system: 01 system('/sbin/start',

    Probably good advice on *nix, but not for the OPs requirement as start is actually a built-in command of the windows shell.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
    In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]
[d/l]
      Besides that, Windows doesn't provide anything like the Unix execve(2) syscall accepting an array of arguments. Instead, if has functions as CreateProcess which take the full command line as a single argument. When perl runs a multi-argument system call, it has to quote and join the arguments into a single line.

      Unfortunately, in Windows the command line parsing is handled by the application itself and so there isn't a unique and standard set of quoting rules as different language runtimes use slightly different sets of rules and so, there are corner cases where perl may fail to quote command arguments properly. That has security implications too.

      See for instance How a Windows program splits its command line into individual arguments.

      Note that I am not advocating against the use of using the multi-argument system and related builtins on Windows, just pointing out that things are not straightforward as when using them on Linux or UNIX systems.

[reply]
[d/l]
        Note that I am not advocating against the use of using the multi-argument system and related builtins on Windows,

        I never do it, because of the reasons you cite.

        And I never understood the predilection *nix people have for "avoiding the shell".

        It seems to me that all of the justifictions I've read -- the bad guys can replace the shell with their program, or insert their program earlier in the search path and variations thereof -- could equally be done to the program you ask the shell to run on your behalf.

        And if they can do either, your system is pretty much owned anyway.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
        In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]

In Section Seekers of Perl Wisdom