Ticket #847 (new todo)

Opened 5 years ago

Last modified 3 years ago

Interpreter - 'exec' and 'spawn' should split own args

Reported by: jkeenan Owned by:
Priority: normal Milestone:
Component: core Version: 1.3.0
Severity: medium Keywords:
Cc: coke Language:
Patch status: Platform: all

Description

This ticket formerly existed as  RT #31144. It was created by Coke on Aug 15 2004. I am moving it to Trac at  the suggestion of whiteknight on his blog, which is also available on  planet.parrotcode (July 17).

Original ticket description:

Have exec and spawn split up their command-line arguments, rather than relying on the operating system shell to do this, which is unsafe.

Here are some files in our distribution that will be relevant to working on this ticket:

config/gen/platform.pm
config/gen/platform/ansi/exec.c
config/gen/platform/generic/exec.c
config/gen/platform/generic/memexec.c
config/gen/platform/openbsd/memexec.c
config/gen/platform/win32/exec.c
src/ops/sys.ops
tools/dev/pbc_to_exe.pir
t/op/spawnw.t
t/pmc/sys.t
docs/book/draft/ch10_opcode_reference.pod
docs/porting_intro.pod

Change History

in reply to: ↑ description ; follow-up: ↓ 2   Changed 5 years ago by jkeenan

Replying to jkeenan:

This ticket formerly existed as  RT #31144. It was created by Coke on Aug 15 2004.

Many of our older RT tickets are the results of the 'ticketization' of TODO or XXX comments found in the source code. Paul T Cochrane opened a couple hundred such tickets two years ago. And, as I look at RT #31144, I believe that Coke was taking the same approach there.

Ticketizing TODO comments, however, only gets us so far toward resolving the issues. If the original inline comments were very terse -- and most of them were -- we of the next generation have to raise questions about the issues before we can start to work on code.

So let me ask some questions that anyone taking up this ticket would have to ask:

1. Can you provide an example of how allowing the shell to break up command-line arguments would be dangerous?

2. OTOH, are there circumstances in which allowing the shell to break up those arguments is perfectly safe?

3. Do we already have other Parrot functions which correctly handle command-line arguments?

4. Here's the source code for the spawnw ops:

inline op spawnw(out INT, in STR) {
  $1 = Parrot_Run_OS_Command(interp, $2);
}

inline op spawnw(out INT, invar PMC) {
  $1 = Parrot_Run_OS_Command_Argv(interp, $2);
}

Each variation runs on a variation of Parrot_Run_OS_Command(). Is that function the real, underlying problem?

5. Is the exec function referred to in this ticket what is now known as Parrot_exec? (Posed because the string exec shows up many times when you grep the repository, but in no cases that self-evidently match the case in this ticket.)

Thank you very much.
kid51

in reply to: ↑ 1   Changed 3 years ago by jkeenan

Can anyone reply to the questions posed in this ticket?

1. Can you provide an example of how allowing the shell to break up command-line arguments would be dangerous? 2. OTOH, are there circumstances in which allowing the shell to break up those arguments is perfectly safe? 3. Do we already have other Parrot functions which correctly handle command-line arguments? 4. Here's the source code for the spawnw ops: {{{ inline op spawnw(out INT, in STR) { $1 = Parrot_Run_OS_Command(interp, $2); } inline op spawnw(out INT, invar PMC) { $1 = Parrot_Run_OS_Command_Argv(interp, $2); } }}} Each variation runs on a variation of Parrot_Run_OS_Command(). Is that function the real, underlying problem? 5. Is the exec function referred to in this ticket what is now known as Parrot_exec? (Posed because the string exec shows up many times when you grep the repository, but in no cases that self-evidently match the case in this ticket.)

Note: See TracTickets for help on using tickets.