feat: allow customizing workspace directory

[DanielleMaywood]

Allow specifying where code-server should be launched into.

[DanielleMaywood]

$_REMOTE_USER_HOME should always be set

[DanielleMaywood]

Moving from \$ARGS to $ARGS because escaping here meant that the script written to file would have the literal $ARGS in it instead of the expanded result, which was not intended.

[mafredri]

Where does ARGS come from and what does it contain? I wonder if we need to worry about quoting and/or newlines?

Right now a ', " or \n would/could break the su command, example:

root@5110bc305062:/# su root -c 'echo hi
>
> there'
hi
bash: -c: line 2: syntax error near unexpected token `newline'
bash: -c: line 2: `>'

[DanielleMaywood]

ARGS comes from the feature. A user could supply additional arguments here that are not covered by the feature. It could contain anything but should be in the form of additional command line arguments.

Maybe we need to escape this? (or just drop it altogether)

[mafredri]

Gotcha, maybe we could use eval for simplicity?

> ARGS="--foo \"some thing\" --'bar'"
> eval "declare -a args=($ARGS)"
> declare -p args
declare -a args=([0]="--foo" [1]="some thing" [2]="--bar")

Used like this:

code-server "${args[@]}"

You can still do something sneaky, like:

ARGS="$(rm -rf /)"

But I don't know if we need care? Someone could just as well include a malicious feature? 🤷🏻‍♂️

The alternative is that we encode supported code-server flags/opts as explicit feature options, which lets us drop ARGS.

[DanielleMaywood]

TIL of eval 😄

I think the best course of action would be to ensure we support every CLI flag with a feature and drop ARGS

[DanielleMaywood]

I'm not sure of a better way to test this other than to grep the created entry point to ensure the directory is in the command to launch code-server

[mafredri]

Would it make sense to verify more of the cmdline? Ports, args, etc?

Alt suggestion (to useless use of cat 😼):

Suggested change

	entrypoint=$(cat /usr/local/bin/code-server-entrypoint)
	check "code-server workspace" grep $'\'code-server.*"/home"\'' <<<"$entrypoint"
	check "code-server workspace" grep $'\'code-server.*"/home"\'' < /usr/local/bin/code-server-entrypoint

[DanielleMaywood]

Each separate feature test could do their own verifications of this yeah (my next PR is using this approach).

[mafredri]

I'm a bit concerned about edge cases with the entrypoint, but otherwise LGTM.

[mafredri]

Where does ARGS come from and what does it contain? I wonder if we need to worry about quoting and/or newlines?

Right now a ', " or \n would/could break the su command, example:

root@5110bc305062:/# su root -c 'echo hi
>
> there'
hi
bash: -c: line 2: syntax error near unexpected token `newline'
bash: -c: line 2: `>'

[mafredri]

Would it make sense to verify more of the cmdline? Ports, args, etc?

Alt suggestion (to useless use of cat 😼):

Suggested change

	entrypoint=$(cat /usr/local/bin/code-server-entrypoint)
	check "code-server workspace" grep $'\'code-server.*"/home"\'' <<<"$entrypoint"
	check "code-server workspace" grep $'\'code-server.*"/home"\'' < /usr/local/bin/code-server-entrypoint

[mafredri]

I'm OK with dropping ARGS btw, but expanded that discussion a bit. Approving since removing ARGS would be fine, keeping them as-is makes it a bit easy to break the command.

[mafredri]

Gotcha, maybe we could use eval for simplicity?

> ARGS="--foo \"some thing\" --'bar'"
> eval "declare -a args=($ARGS)"
> declare -p args
declare -a args=([0]="--foo" [1]="some thing" [2]="--bar")

Used like this:

code-server "${args[@]}"

You can still do something sneaky, like:

ARGS="$(rm -rf /)"

But I don't know if we need care? Someone could just as well include a malicious feature? 🤷🏻‍♂️

The alternative is that we encode supported code-server flags/opts as explicit feature options, which lets us drop ARGS.