Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow shell expanded .conf values #14

Merged
merged 6 commits into from
Dec 3, 2020

Conversation

lrascao
Copy link
Contributor

@lrascao lrascao commented Nov 9, 2020

Allow for shell commmand substitution of .conf values,
only the `ShellCommand` form is allowed.

@lrascao
Copy link
Contributor Author

lrascao commented Nov 9, 2020

This one should be merged after #13 and conflicts have been resolved

@lrascao lrascao force-pushed the feature/shell_based_conf_values branch 9 times, most recently from 3e9230c to 3c8439a Compare November 11, 2020 15:14
@lrascao
Copy link
Contributor Author

lrascao commented Nov 11, 2020

64c7aca has the actual change, 3c8439a is needed to bring up the coverage percentage so coveralls green lights this

@lrascao
Copy link
Contributor Author

lrascao commented Nov 11, 2020

@lukebakken this is all i have in the pipe for 2.5.0, proposed merge order is #12 , #13 , pause for rebase and then #14

Copy link
Collaborator

@lukebakken lukebakken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My feeling is that executing arbitrary shell commands will not be appreciated by end-users (cc @michaelklishin)

@lrascao can you give a concrete example of the kinds of problems this change addresses?

% first get the current cwd so we can restore it later
{ok, Cwd0} = file:get_cwd(),
file:set_cwd(filename:dirname(Filename)),
ShellValue = os:cmd(Cmd),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can hear the screams of the security review now.

@lrascao lrascao force-pushed the feature/shell_based_conf_values branch 2 times, most recently from d225b66 to 776479a Compare December 2, 2020 11:11
@lrascao
Copy link
Contributor Author

lrascao commented Dec 2, 2020

My feeling is that executing arbitrary shell commands will not be appreciated by end-users (cc @michaelklishin)

I hadn't really considered the security aspect of it, i guess mostly due to the fact that a malicious actor that is able to add arbitrary shell commands to the .conf file should also be able to do a lot of other things (eg. find the cookie of the node and connect remotely and os:cmd becomes available as well, alter the extended start script which is also just shell script), if this is an issue we can probably come up with some alternative to mitigate it

@lrascao can you give a concrete example of the kinds of problems this change addresses?

Sure, a specific one i'm currently working on is running the Erlang VM on Kubernetes. Without getting into too much detail, k8s offers two features (configMap and downwardAPI) that allow us to expose the resources that are being requested as files in the Erlang VM container. A typical scenario is tweaking the number of VM schedulers available based on the resource limits imposed (the adoptingerlang.org site section on k8s has more detail on this). So here's my vision on this:

  • Using the configMap/downwardAPI features, you expose a file under etc/conf.d/erlang-vm-total-schedulers containing a single number which is the desired total number of schedulers. K8s doesn't allow any formatting of this data so the file really only contains a number
  • A erlang-vm-k8s.conf file is generated in etc/conf.d that specifies the erlang.schedulers.total parameter as:
erlang.schedulers.total = `cat erlang-vm-total-schedulers`
  • erlang-vm-k8s.conf is automatically picked up and used to generate the apropriate vm.args that will instruct the VM to only run as many schedulers

If the security restriction is a concern i suppose a viable alternative would be to make use the $() substitution feature to also support files, it's not as flexible as running arbitrary shell script though, thoughts?

@lukebakken
Copy link
Collaborator

If the security restriction is a concern i suppose a viable alternative would be to make use the $() substitution feature to also support files

Yes, let's do that. Please use the same syntax as what bash supports which is $(< path/to/file):

$ echo 'FILE CONTENTS' > testfile.txt

$ echo $(<testfile.txt)
FILE CONTENTS

So coveralls can shut up already and green light this PR.
Allows defining .conf values in the format `$(<FILENAME)`, the included
file contents will be read and used as the setting value.
@lrascao lrascao force-pushed the feature/shell_based_conf_values branch from 776479a to 0de26f1 Compare December 3, 2020 10:48
@lrascao
Copy link
Contributor Author

lrascao commented Dec 3, 2020

@lukebakken reworked as agreed

@lrascao lrascao requested a review from lukebakken December 3, 2020 10:49
@lrascao lrascao changed the title Allow shell expanded .conf values [WIP] Allow shell expanded .conf values Dec 3, 2020
@lrascao lrascao marked this pull request as draft December 3, 2020 10:53
@lrascao lrascao changed the title [WIP] Allow shell expanded .conf values Allow shell expanded .conf values Dec 3, 2020
@lrascao lrascao marked this pull request as ready for review December 3, 2020 12:10
Copy link
Collaborator

@lukebakken lukebakken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lrascao if you have time to review the commits I added to handle some edge-cases, I would appreciate it!

@lukebakken lukebakken self-requested a review December 3, 2020 18:10
@lrascao
Copy link
Contributor Author

lrascao commented Dec 3, 2020

👍 changes look good, let's hope coveralls doesn't come back with more coverage demands

@lukebakken lukebakken added this to the 2.5.0 milestone Dec 3, 2020
@lukebakken lukebakken self-assigned this Dec 3, 2020
@lukebakken lukebakken merged commit 9ac2f9d into Kyorai:master Dec 3, 2020
@lrascao lrascao deleted the feature/shell_based_conf_values branch December 4, 2020 09:52
@lrascao
Copy link
Contributor Author

lrascao commented Dec 4, 2020

@lukebakken that's the end of my pipeline, if there's nothing else that you intend do add could you please cut a 2.5.0 and push it to hex? thanks!

@lukebakken
Copy link
Collaborator

@lrascao I am blocked by this issue - erlef/rebar3_hex#194

@lukebakken
Copy link
Collaborator

@lrascao https://hex.pm/packages/cuttlefish/2.5.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants