FTR, the

ichorcna

modules are problematic, because the software (not the module) parses completely untrusted input (I wrote to the Ha lab with the details), but that leaves the question: unless there's an input to the module, you're fairly limited to what you can do in the configuration. So, in case I have a process that accepts an optional parameter that's normally defined in

args

, how can I manipulate it? (reason: restrict what's sent to ichorCNA to mitigate the problem)

I'm a bit unclear to what you mean by it parses untrusted input. If you control the pipeline, presumably you control what is passed to the module? That aside, you can set

args

using

ext.args

in a custom config for that process.

The R code does

eval(parse(text=etcetc))

which means tha anything can be passed to it (

system("cat /etc/passwd")

or

system("rm -f /some/file")

, so I want to "assemble" the string I send to the code: e.g., instead of taking "paste0('chr', 1:22)` ideally I should handle

params.chromosomes

and build that string myself (enforcing what can be supplied as input to that CLI parameter)

If you want to make chromosomes a separate input parameter to the module then I'd support that

Well, we have 3 types of chromosome input 1. Use: these are used to call CN alterations; 2. Train: These are used to train the EM model of ichorCNA at the start 3. Normalize: these are used to perform normalization I don't mind 3 inputs, and if the other 2 are missing, fall back to the 1st? The issue is not just there, but for the rest you can just do simple string formatting, it's just for chromosomes that's more complicated. If you agree with the design, or have better solutions, I'm happy to provide a PR!

we don't tend to worry to be honest about this kind of code injection

I'm still confused as to what part of this is any different to any bash script we have in modules which takes

args

. There is fundamentally nothing stopping someone passing something like

; rm -rf /;

to

args

afaik? I think for some modules this would probably error because

args

is in the middle of a command and it breaks the command, but for others it will likely run

Yeah, or you could setup a

beforeScript

to do what you like

Probably no need in the end, I got told that this will get fixed upstream