Expose gigl vars as env vars for the custom luancher

[kmontemayor2-sc]

Do this so custom launchers can get the task config, etc.

The alternative approach here is that we can use omegaconf but as we discussed offline that may be more complicated as the resolution would change often.

[semgrep-code-snapchat]

Semgrep identified an issue in your code:

The subprocess.run() call uses shell=True on user-controlled command strings, allowing shell injection attacks that could execute arbitrary commands with the process's privileges.

More details about this

The subprocess.run() call executes shell_line with shell=True, which spawns a shell process to interpret the command. This is dangerous because if resolved_command or any element in resolved_args comes from untrusted input (e.g., user-provided configuration, external data), an attacker can inject arbitrary shell commands.

For example, if an attacker controls custom_resource_config.command and sets it to id; rm -rf /, the shell will execute both id and the destructive rm -rf / command. Even though shlex.quote() escapes individual arguments, it doesn't protect against injection in the command itself—only in the args list. An attacker who controls the command field can bypass this protection entirely.

Exploit scenario:

1. Attacker provides custom_resource_config.command = "echo test; cat /etc/passwd #"
2. After joining with args, shell_line becomes something like "echo test; cat /etc/passwd #"
3. When subprocess.run() executes this with shell=True, the shell interprets the semicolon as a command separator
4. Both echo test and cat /etc/passwd execute, leaking sensitive system files
5. If the process runs with elevated privileges, the attacker can exfiltrate or modify sensitive data

The shell inherits environment variables and settings from the parent process, which further expands the attack surface. Using shell=False would treat the entire string as a single command name rather than allowing shell metacharacters to be interpreted.

To resolve this comment:

💡 Follow autofix suggestion

Suggested change

	subprocess.run(shell_line, shell=True, check=True, env=env)
	subprocess.run(shell_line, shell=False, check=True, env=env)

View step-by-step instructions

1. Replace subprocess.run(shell_line, shell=True, check=True) with an invocation that does not use shell=True.
2. Change the code to directly pass the command and arguments as a list, rather than joining into a string. Use: subprocess.run([resolved_command] + resolved_args, check=True).
3. Remove any uses of shlex.quote when building the argument list, since quoting is only necessary when passing a string to the shell.
4. Ensure that resolved_command and every item in resolved_args are unquoted strings representing the command and its arguments.

Passing the command and arguments as a list with shell=False (the default) is safer, because it avoids any interpretation by a shell, preventing command injection vulnerabilities.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by subprocess-shell-true.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[svij-sc]

Might be good opportunity to also consolidate existing VAI launchers to use env vars too instead of injected runtime args:

GiGL/gigl/src/common/vertex_ai_launcher.py

Lines 256 to 264 in 454b54b

	job_args = (
	[
	f"--job_name={job_name}",
	f"--task_config_uri={task_config_uri}",
	f"--resource_config_uri={resource_config_uri}",
	]
	+ (["--use_cuda"] if use_cuda else [])
	+ ([f"--{k}={v}" for k, v in args.items()])
	)

Adopting one distinct pattern will make it easier for us to maintain the different code paths, and I am happy to adapt the env variables given prior discussed arguments as the golden path, but lets also old our old injection paths in existing launchers.

[svij-sc]

We have RESOURCE_CONFIG_OS_ENV already defined in code.
See: gigl/env/pipelines_config.py

Some opportunity to consolidate / refactor.

[kmontemayor2-sc]

Hmmm, how about a new gigl/env/constants.py? And then migrate the existing RC one in as a follow up?

I think there's two things here tho:

1. These env vars aren't always defined (though we can also add them to the VAI path I suppose which is probably a good idea?)
2. now we have both dep_constants and constants that may get confusing.

WDYT? I'm fine with adding constants and then moving in the existing var in a future PR (in additional to exposing in our VAI jobs)

[svij-sc]

This plan sounds good to me.
One small suggestion; should we export these variables @ the start of each component too where possible?

i.e. currently we have initialize_metrics(task_config_uri=task_config_uri, service_name=args.job_name) being called at the start of every component. We could refactor this to initialize_gigl_env which can both init the metrics and make available these env variables. Having the same behaviour throughout will bring down the long term complexity of the codebase.

[svij-sc]

It would also simplify our code below for "passing the env variables to subprocesses" as those env variables would already be available everywhere.

But open to thoughts.

[kmontemayor2-sc]

One small suggestion; should we export these variables @ the start of each component too where possible?

Yes! I can look into setting this up as a follow up :)

[kmontemayor2-sc]

I'd prefer to have this PR in first as the other changes may be somewhat complicated still (and I'm not sure we need all of these things to be exposed globally)

[svij-sc]

Could you remind me what does cpu and cuda docker images mean in this case?

[kmontemayor2-sc]

they're the containers we launch on e.x vai for custom training.

[svij-sc]

could you remind me what is the process command in this case?
Adding comments could help.

[kmontemayor2-sc]

This is like python -m my.launcher.code I guess we can skip this one?

[svij-sc]

cant this test and the first test be both combined to reduce verbosity?

[svij-sc]

In our code we usually default these
cuda_docker_uri or DEFAULT_GIGL_RELEASE_SRC_IMAGE_CUDA

Could you remind me the reason we need to deviate here?

[kmontemayor2-sc]

No reason, we can use the default ones if you prefer.