Skip Menu |
Report information
Id: 122046
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: tsibley <tsibley [at] cpan.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type:
  • unknown
  • Patch
Perl Version: (no value)
Fixed In: (no value)



To: perlbug [...] perl.org
Subject: [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
From: Thomas Sibley <tsibley [...] cpan.org>
Date: Thu, 05 Jun 2014 10:25:31 -0700
Patch against blead attached.

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #122046] [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
To: perl5 porters <perl5-porters [...] perl.org>
CC: bugs-bitbucket [...] rt.perl.org
Date: Thu, 5 Jun 2014 15:30:39 -0400
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 676b
On Thu, Jun 5, 2014 at 1:26 PM, Thomas Sibley <perlbug-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Thomas Sibley
# Please include the string:  [perl #122046]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=122046 >


Patch against blead attached.

The patch is accurate.

>perl -e"system 'dir' and die;"
 Volume in drive C is OS
...

>perl -e"system { 'dir' } 'dir' and die;"
Died at -e line 1.

Keep in mind that dir is a shell builtin. Expected behaviour:

$ perl -e'system "set" and die;'
Died at -e line 1.

$ perl -e'system { "set" } "set" and die;'
Died at -e line 1.

- Eric

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 218b
On Thu Jun 05 10:26:09 2014, tsibley wrote: Show quoted text
> Patch against blead attached.
Can we not have a huge block of code in a commit message? That should be in the ticket, not the git repo. -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #122046] [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
To: perlbug-followup [...] perl.org
Date: Thu, 05 Jun 2014 14:28:30 -0700
From: Thomas Sibley <tsibley [...] cpan.org>
Download (untitled) / with headers
text/plain 331b
On 06/05/2014 12:57 PM, bulk88 via RT wrote: Show quoted text
> On Thu Jun 05 10:26:09 2014, tsibley wrote:
>> Patch against blead attached.
> > Can we not have a huge block of code in a commit message? That should > be in the ticket, not the git repo.
I'm fine with a committer trimming it before applying, but why in the world does it matter?
To: Thomas Sibley <tsibley [...] cpan.org>, perlbug-followup [...] perl.org
Subject: Re: [perl #122046] [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
From: Karl Williamson <public [...] khwilliamson.com>
Date: Sat, 07 Jun 2014 17:39:52 -0600
Download (untitled) / with headers
text/plain 1.7k
On 06/05/2014 03:28 PM, Thomas Sibley wrote: Show quoted text
> On 06/05/2014 12:57 PM, bulk88 via RT wrote:
>> On Thu Jun 05 10:26:09 2014, tsibley wrote:
>>> Patch against blead attached.
>> >> Can we not have a huge block of code in a commit message? That should >> be in the ticket, not the git repo.
> > I'm fine with a committer trimming it before applying, but why in the > world does it matter? >
It matters because some people do 'git log' all the time (me for example), many times a day. The main audience for a commit message are people who are looking to keep up with what's changing in the Perl core. Some do it for idle curiosity; some do it to see how changes might affect the portions of Perl that they especially care about; and some are watchdogs trying to prevent flaws from entering the code. As such, the commit message should state briefly what is changing, and if not obvious, why. Over time the commit messages have gotten more detailed. I know that I am trying to write better commit messages than I used to. It becomes a pain to do excavating of commit messages as time goes by. The blame log may have multiple changes to a line that one has to go back through to find the original message that might have made the purpose clear for a given line. For that reason, I think that much of the detail for commits should be in comments which stay attached to their code. And I do think that we tend to err in putting stuff in the commit message that should be in the code. Commit messages may well contain small snippets of code, or larger snippets of pseudo-code (with unnecessary detail elided out) that clarify what's going on. But try doing a 'git log' and see how ungainly and distracting large snippets of code are in them
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 809b
On Sat Jun 07 16:40:37 2014, public@khwilliamson.com wrote: Show quoted text
> On 06/05/2014 03:28 PM, Thomas Sibley wrote:
> > On 06/05/2014 12:57 PM, bulk88 via RT wrote:
> >> On Thu Jun 05 10:26:09 2014, tsibley wrote:
> >>> Patch against blead attached.
> >> > >> Can we not have a huge block of code in a commit message? That should > >> be in the ticket, not the git repo.
> > > > I'm fine with a committer trimming it before applying, but why in the > > world does it matter? > >
> > It matters because some people do 'git log' all the time (me for > example), many times a day.
I worry more about repo size/CPU complexity/blame speed (I often use gitweb than my local blame tool since its faster in rendering time). I dont want to see a nytprof report page in the commit message. -- bulk88 ~ bulk88 at hotmail.com
To: Karl Williamson <public [...] khwilliamson.com>, perlbug-followup [...] perl.org
Subject: Re: [perl #122046] [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
From: Thomas Sibley <tsibley [...] cpan.org>
Date: Sat, 07 Jun 2014 22:15:49 -0700
Download (untitled) / with headers
text/plain 1.6k
On 06/07/2014 04:39 PM, Karl Williamson wrote: Show quoted text
> On 06/05/2014 03:28 PM, Thomas Sibley wrote:
>> On 06/05/2014 12:57 PM, bulk88 via RT wrote:
>>> Can we not have a huge block of code in a commit message? That should >>> be in the ticket, not the git repo.
>> >> I'm fine with a committer trimming it before applying, but why in the >> world does it matter? >>
> > It matters because some people do 'git log' all the time (me for > example), many times a day.
I can see how reading it in plain old `git log` would be a chore. I find it easier to stay on top of commits by reading the first line summaries and only reaching for the full message or even full diff when I want to know more (using tools that make this easy). Given that, I tend to not care as much how much detail is shoved into a commit message, because it's only there if I want to see it and isn't in the way otherwise. Though I thought the code snippet explained the strange situation fairly well, in retrospect now it's a poor excuse for not just describing the behaviour in another sentence or two. A new patch is attached. Show quoted text
> It becomes a pain to do excavating of commit messages as time goes by. > The blame log may have multiple changes to a line that one has to go > back through to find the original message that might have made the > purpose clear for a given line. For that reason, I think that much of > the detail for commits should be in comments which stay attached to > their code. And I do think that we tend to err in putting stuff in the > commit message that should be in the code.
This seems tangential to the commit message in question, unless you're suggesting there should be comments added to the pod in this case?

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 325b
On Sat Jun 07 22:16:33 2014, tsibley wrote: Show quoted text
> Though I thought the code snippet explained the strange situation fairly > well, in retrospect now it's a poor excuse for not just describing the > behaviour in another sentence or two. A new patch is attached.
Thanks, applied as 94d4006a6dfdde1becb6ac3d43bd51a5b9ffd95f. Tony
Subject: shell-less system() was: [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Thu Jun 05 10:26:09 2014, tsibley wrote: Show quoted text
> Patch against blead attached.
FWIW, at an offline event, I spoke with a Perl programmer whose day job had a very interesting security policy. His employer uses all Win 7 machines. Any attempt run the "cmd.exe" process (it won't actually start), will result in a very seriously investigated automatic alert to Information Security Department. The cmd.exe executable was replaced with a honeypot executable. This nearly resulted in him being terminated for attempting to hack his employer's IT system. He was using Strawberry Perl, and he got it whitelisted previously by the legal dept of his employer. Since there was no way to reliably get the cmd.exe attempt out of Strawberry Perl (or really Win32 Perl), and he is not allowed to compile his own Win32 Perl, he promptly switched Cygwin Perl and never looked back since cygperl will never run cmd.exe unless you put that string into system(). So there is atleast one person who would like a way to permanently disable the "shell" part of `` and system() on Win32 Perl. I don't think this should be implemented for 1 person that probably comfortably uses Cygperl, but if a chorus of requests come for this, (I'd guess it would be a special var), its something to implement. -- bulk88 ~ bulk88 at hotmail.com
Date: Mon, 9 Jun 2014 10:59:57 -0700
From: Jan Dubois <jand [...] activestate.com>
Subject: Re: [perl #122046] shell-less system() was: [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
To: bulk 88 via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 637b
On Sun, Jun 8, 2014 at 9:10 PM, bulk88 via RT <perlbug-followup@perl.org> wrote: FWIW, it doesn't make any sense to me, forbidding people from running cmd.exe, but allowing to run perl.exe that in turn is allowed to invoke any other executable on the system, but again not cmd.exe. So they allow Cygwin to be installed, and /bin/sh is not a honeypot too? I don't think Perl should be modified for this, but it is actually easy to implement at the Perl script level: Perl invokes cmd.exe via PATH, so if you remove the system32 directory from $ENV{PATH}, then system() will no longer be able to invoke it "by accident". Cheers, -Jan
To: bulk 88 via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #122046] shell-less system() was: [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
From: Jan Dubois <jand [...] activestate.com>
Date: Mon, 9 Jun 2014 11:30:02 -0700
Download (untitled) / with headers
text/plain 453b
On Mon, Jun 9, 2014 at 10:59 AM, Jan Dubois <jand@activestate.com> wrote: Show quoted text
> [...] it is actually > easy to implement at the Perl script level: Perl invokes cmd.exe via > PATH, so if you remove the system32 directory from $ENV{PATH}, then > system() will no longer be able to invoke it "by accident".
Tested sample code: $ENV{PATH} = join ';', grep !-f "$_/cmd.exe", split /;/, $ENV{PATH}; system("echo Hello World!"); warn $?>>8 if $?; Cheers, -Jan
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.5k
On Mon Jun 09 11:00:32 2014, jdb wrote: Show quoted text
> On Sun, Jun 8, 2014 at 9:10 PM, bulk88 via RT <perlbug- > followup@perl.org> wrote: > > FWIW, it doesn't make any sense to me, forbidding people from running > cmd.exe, but allowing to run perl.exe that in turn is allowed to > invoke any other executable on the system, but again not cmd.exe. > > So they allow Cygwin to be installed, and /bin/sh is not a honeypot > too?
Yes, they approved Cygwin. cmd.exe wasn't banned by the employer but the ban came from an outside source the employer contracts with for security services and/or software, since the cmd.exe ban isn't an in-house policy, the person I spoke with would have to make the employer get rid of the contractor, which isn't going to happen. The employer previously didn't use Perl before hiring the person but they used everything else under the sun. /bin/sh isn't the "Windows Command Prompt" so its not on the 3rd party blacklist. I asked him if he could rename cmd.exe or bring it on a USB stick. He said he didn't know if it would catch him by CRC, and the next time he will "terminated with cause" if he is caught by the security system again, and he won't risk his job. I can't say who or what the employer is, for obvious reasons, but the owner isn't a natural person, or a single person, you can "talk with", and its run by a "board" or "council". Now I won't speak about the person above's particular situation. For years I've seen articles of "hack your schools computer with the command prompt". Like http://www.wikihow.com/Make-Command-Prompt-Appear-at-School http://www.instructables.com/id/Getting-around-command-prompt-restrictions-for-rea/ , I've also read about the change the console's font, size and color to look like a word processor. So to see cmd.exe banned in a corporate security product, for libraries, schools, large corporations, isn't far fetched at all. But to use the "public library terminal" profile for a financial company or an engineering firm, lol Show quoted text
> I don't think Perl should be modified for this, but it is actually > easy to implement at the Perl script level: Perl invokes cmd.exe via > PATH, so if you remove the system32 directory from $ENV{PATH}, then > system() will no longer be able to invoke it "by accident".
I thought that would make loading XS modules or creating new processes impossible while path doesn't have system32. KnownDLLs does allow some core dlls to be found even outside of path, but the list is very small. I'll try suggesting that in the future if I ever hear of someone else with this problem again. -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #122046] [PATCH] Document that "exec LIST" and "system LIST" may fall back to the shell on Win32
To: perlbug-followup <perlbug-followup [...] perl.org>
CC: perl5 porters <perl5-porters [...] perl.org>
Date: Mon, 9 Jun 2014 23:46:31 -0400
From: Eric Brine <ikegami [...] adaelis.com>
Download (untitled) / with headers
text/plain 132b
Looks like env var PERL5SHELL overrides the shell choice, so you could point it to something other than cmd.exe. (See C<get_shell>)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org