Skip to content

bug: templates using sh -c inlining for init_script are vulnerable to quoting breakage #723

@dannykopping

Description

@dannykopping

Problem

Several templates inline the agent init script via:

sudo -u '${linux_user}' sh -c '${init_script}'

This pattern is fragile: if the upstream bootstrap script (provisionersdk/scripts/bootstrap_linux.sh in coder/coder) ever contains a single quote (apostrophe), the shell quoting breaks silently. The agent fails to start with no clear error.

This just happened — see coder/coder#22062. A comment containing exec'ing was added to the bootstrap script, breaking all templates using this pattern.

Affected templates

coder/templates/aws-linux          — cloud-init/userdata.sh.tftpl
coder/templates/gcp-linux          — main.tf (metadata_startup_script)
mossylion/templates/scaleway-instance — cloud-init/userdata.sh.tftpl
ericpaulsen/templates/k8s-username — main.tf

Templates already using safe patterns

These templates write the init script as file content via cloud-config write_files or similar, avoiding the quoting issue entirely:

coder/templates/azure-linux        — cloud-init write_files + systemd
coder/templates/digitalocean-linux — cloud-init write_files

Proposed fix

Update the affected templates to use the same write_files approach as azure-linux and digitalocean-linux. Instead of inlining the script into sh -c '...', write it to a file and execute it:

write_files:
  - path: /opt/coder/init
    permissions: "0755"
    encoding: b64
    content: ${init_script}

Then execute via a systemd unit or runcmd:

runcmd:
  - sudo -u ${linux_user} /opt/coder/init

This is immune to quoting issues since the script content is base64-encoded and written as a file rather than inlined into a shell command.

Related

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions