G'day p5p,
This is just a nudge on this bug, since I potentially have some free
cycles and can start taking actions to correct it. I'm also posting a
simple example so you don't have to read the original bug report. This
comes courtesy of http://perlmonks.org/?node_id=625960 :
Show quoted text

---cut here---
system("echo", "%PATH%"); # works fine on Win32
And here's the crux of the problem. Currently, that does work fine under
Windows. According to the documention in perldoc -f exec, it shouldn't:
Using an indirect object with "exec" or "system" is also more
secure. This usage (which also works fine with system()) forces
interpretation of the arguments as a multivalued list, even if the
list had just one argu- ment. That way you're safe from the shell
expanding wildcards or splitting up words with whitespace in them.
@args = ( "echo surprise" ); exec @args; # subject to shell escapes
# if @args == 1
exec { $args[0] } @args; # safe even with one-arg list
Under Windows, Perl's system() is currently doing exactly what it
shouldn't do, interpreting shell metacharacters and commands when called
with multiple arguments. In my opinion, this is a bug in Perl.

---cut here---
My fear here is that people may expecting multi-argument system under
Windows to use the shell anyway, and the previously referenced node on
Perlmonks is a prime example of this.
Do we:
1) Change multi-argument system() under Windows to never use the code.
This may break existing deployed code, and hence I feel is a Bad Idea.
2) Emit some sort of deprecation warning when multi-arg system() under
Windows uses the shell and then move to (1). I think that this is an
even worse idea, because it's nigh impossible to tell when multi-arg
system() is being called with the expectation of the shell getting involved.
3) Leave the code as-is, and fix the documentation. This is easy, and
doesn't break existing systems. However it leaves system() behaving in
an inconsistent fashion across platforms.
4) Same as (3), but provide some sort of mechanism to *make* them work
consistently if desired, preferably lexical in scope. For example:
use feature 'system';
Except probably with a less ambiguous name than just 'system'. This
could be a no-op under Unix, and actually do something useful under
Windows. Except that last I checked system() and exec() take indirect
arguments, hence they can't be prototyped, hence this is hard. It also
provides no way of getting consistent behaviour with Perl < 5.10.
5) Same a (3), but bundle a core module that people can use to make it
consistent. Except this bloats the core, and may be a no-op under Unix.
It has the advantage that the code can be potentially distributed on
the CPAN, so it can be installed on older Perls if required.
Feedback and thoughts would be greatly appreciated. If you don't know,
or don't care, then vote (3), as it's better than nothing.
Cheerio,
Paul
--
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681

(Reposting to p5p, since I didn't realise that a simple response via RT
wouldn't forward to p5p)
G'day p5p,
This is just a nudge on this bug, since I potentially have some free
cycles and can start taking actions to correct it. I'm also posting a
simple example so you don't have to read the original bug report. This
comes courtesy of http://perlmonks.org/?node_id=625960 :
Show quoted text

---cut here---
system("echo", "%PATH%"); # works fine on Win32
And here's the crux of the problem. Currently, that does work fine under
Windows. According to the documentation in perldoc -f exec, it shouldn't:
Using an indirect object with "exec" or "system" is also more
secure. This usage (which also works fine with system()) forces
interpretation of the arguments as a multivalued list, even if the
list had just one argu- ment. That way you're safe from the shell
expanding wildcards or splitting up words with whitespace in them.
@args = ( "echo surprise" ); exec @args; # subject to shell escapes
# if @args == 1
exec { $args[0] } @args; # safe even with one-arg list
Under Windows, Perl's system() is currently doing exactly what it
shouldn't do, interpreting shell metacharacters and commands when called
with multiple arguments. In my opinion, this is a bug in Perl.

---cut here---
My fear here is that people may expecting multi-argument system under
Windows to use the shell anyway, and the previously referenced node on
Perlmonks is a prime example of this.
Do we:
1) Change multi-argument system() under Windows to never use the code.
This may break existing deployed code, and hence I feel is a Bad Idea.
2) Emit some sort of deprecation warning when multi-arg system() under
Windows uses the shell and then move to (1). I think that this is an
even worse idea, because it's nigh impossible to tell when multi-arg
system() is being called with the expectation of the shell getting involved.
3) Leave the code as-is, and fix the documentation. This is easy, and
doesn't break existing systems. However it leaves system() behaving in
an inconsistent fashion across platforms.
4) Same as (3), but provide some sort of mechanism to *make* them work
consistently if desired, preferably lexical in scope. For example:
use feature 'system';
Except probably with a less ambiguous name than just 'system'. This
could be a no-op under Unix, and actually do something useful under
Windows. Except that last I checked system() and exec() take indirect
arguments, hence they can't be prototyped, hence this is hard. It also
provides no way of getting consistent behaviour with Perl < 5.10.
5) Same a (3), but bundle a core module that people can use to make it
consistent. Except this bloats the core, and may be a no-op under Unix.
It has the advantage that the code can be potentially distributed on
the CPAN, so it can be installed on older Perls if required.
Feedback and thoughts would be greatly appreciated. If you don't know,
or don't care, then vote (3), as it's better than nothing.
Cheerio,
Paul
--
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681

> (Reposting to p5p, since I didn't realise that a simple response via RT
> wouldn't forward to p5p)
>
> G'day p5p,
>
> This is just a nudge on this bug, since I potentially have some free
> cycles and can start taking actions to correct it. I'm also posting a
> simple example so you don't have to read the original bug report. This
> comes courtesy of http://perlmonks.org/?node_id=625960 :
>
> ---cut here---
>
> system("echo", "%PATH%"); # works fine on Win32
>
> And here's the crux of the problem. Currently, that does work fine under
> Windows. According to the documentation in perldoc -f exec, it shouldn't:
>
> Using an indirect object with "exec" or "system" is also more
> secure. This usage (which also works fine with system()) forces
> interpretation of the arguments as a multivalued list, even if the
> list had just one argu- ment. That way you're safe from the shell
> expanding wildcards or splitting up words with whitespace in them.
>
> @args = ( "echo surprise" ); exec @args; # subject to shell escapes
> # if @args == 1
>
> exec { $args[0] } @args; # safe even with one-arg list
>
> Under Windows, Perl's system() is currently doing exactly what it
> shouldn't do, interpreting shell metacharacters and commands when called
> with multiple arguments. In my opinion, this is a bug in Perl.
>
> ---cut here---
>
> My fear here is that people may expecting multi-argument system under
> Windows to use the shell anyway, and the previously referenced node on
> Perlmonks is a prime example of this.
>
> Do we:
>
> 1) Change multi-argument system() under Windows to never use the code.
> This may break existing deployed code, and hence I feel is a Bad Idea.

If its done as part of a major upgrade its fair IMO.
But if Jan Dubois or Steve Hay were to disagree with me id bow to their opinion.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"

>
> But if Jan Dubois or Steve Hay were to disagree with me id bow to
> their opinion.
>
> Yves
>
>

CCing them.
I played around with this bug a little bit, when you feed a list to
win32 system, each scalar is double quoted. I couldn't cause any
additional execution through using "&"s.
system('echo', ' & echo JAPH');
becomes
echo " & echo JAPH"
which fails,so it is retried to CreateProcess as
cmd.exe /x/d/c "echo " & echo JAPH""
yes those 2 double quotes look funny.
The result printed to console is
Show quoted text