Skip to content

docker_run_flags: Shellescape any provided values #811

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

Merged
merged 7 commits into from
Oct 12, 2022

Conversation

neomilium
Copy link
Contributor

@neomilium neomilium commented Mar 28, 2022

When passing an environment variable with special characters, it can broke the script or produce unexpected behavior.
I encountered two of them:

  • If a $ is in environment variable, its interpolated as a variable
  • If a " is in environment variable, it broke the end of string, so the script

This PR contains a commit to escape any value that will be pushed in the docker start script.

@neomilium neomilium requested a review from a team as a code owner March 28, 2022 17:39
@puppet-community-rangefinder
Copy link

docker_run_flags is a function

Breaking changes to this file WILL impact these 1 modules (exact match):
Breaking changes to this file MAY impact these 6 modules (near match):

This module is declared in 6 of 579 indexed public Puppetfiles.


These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

@neomilium neomilium marked this pull request as draft March 28, 2022 17:39
@CLAassistant
Copy link

CLAassistant commented Mar 28, 2022

CLA assistant check
All committers have signed the CLA.

@neomilium neomilium changed the title WIP: docker_run_flags: Shellescape any provided values docker_run_flags: Shellescape any provided values Mar 28, 2022
@chelnak
Copy link
Contributor

chelnak commented Mar 28, 2022

Hey 👋

Can you set this PR to ready for review?

thanks!

@smortex smortex marked this pull request as ready for review March 29, 2022 00:34
@smortex
Copy link
Collaborator

smortex commented Mar 29, 2022

I am wondering if the CI failures are relevant… Like volume-1:C:\volume_1 being escaped as volume-1:C:\\volume_1… Not sure about how to check this…

@neomilium
Copy link
Contributor Author

@chelnak Test added by @smortex, PR is now ready.

@chelnak
Copy link
Contributor

chelnak commented Apr 3, 2022

@smortex - i'll take a closer look at this tomorrow. Seems odd that all of the failures here are for Windows and they don't seem to be on the nightly tests either..

@chelnak chelnak self-assigned this Apr 3, 2022
@smortex
Copy link
Collaborator

smortex commented Apr 13, 2022

@neomilium @chelnak I added a commit that seems to help… but escaping on windows is total nonsense and I am sure of nothing 😱

Some windows node pass, the one failing seems to fail earlier than the code added / changed here and the failures might be the result of some external service not being reliable… maybe?

@smortex smortex self-requested a review April 18, 2022 16:54
subject = args[0]

if self['facts'] && self['facts']['os']['family'] == 'windows'
%("#{subject.gsub('"', '\\"')}")
Copy link
Collaborator

Choose a reason for hiding this comment

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

is that just because the shellescape function is designed for linux? what about patching https://github.com/puppetlabs/puppetlabs-stdlib/blob/main/lib/puppet/parser/functions/shell_escape.rb instead?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The more I am thinking about it, the more I am concerned about cmd.exe escaping vs. powershell escaping: they seem to be different in incompatible ways:

Maybe the stdlib should have 3 shell escape functions: shell_escape, powershell_escape and cmd_escape, then modules could have a local escape function which call the right escape function on windows depending on what the module is using?

Copy link
Collaborator

Choose a reason for hiding this comment

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

that sounds like a good idea

Copy link
Collaborator

Choose a reason for hiding this comment

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

puppetlabs/puppetlabs-stdlib#1235 was merged in stdlib. When we have a new release with this code, we will be able to move on with this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

@smortex Looks like these changes are available as of v8.2.0 of stdlib

Happy to work with someone to get this through.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Awesome! I added a commit to rely on this new code. Let's see what the CI think about it 😉

neomilium and others added 3 commits May 31, 2022 09:36
Ruby Shellwords#shellescape "Escapes a string so that it can be safely
used in a Bourne shell command line".  This is fine for a UNIX like
operating system, but windows does not complies with this.

Attempt to fix CI by manually "escaping" strings on windows (i.e. quote
them and escape quotes with a backslash), and relying on shellescape for
other operating systems.
smortex added 2 commits May 31, 2022 11:09
At the cost of one more function call, we gain in readability and what
the docker::escape functions is more straightforward.
Escaped strings should not be quotted.

While here, also rework the way networks are escaped: the previous code
was generating invalid parameters.
@smortex smortex marked this pull request as draft May 31, 2022 21:12
@smortex
Copy link
Collaborator

smortex commented Jun 1, 2022

@neomilium have you had a chance to see if the issue you originally tried to fix with this PR is indeed fixed with all these changes?

bastelfreak
bastelfreak previously approved these changes Jun 1, 2022
@canihavethisone
Copy link
Contributor

canihavethisone commented Jun 11, 2022

@smortex @chelnak @bastelfreak - why has stdlib been raised to min v8.2.0 in the pull request? That is very high and will have breaking impact when combined with a number of other available modules

@smortex
Copy link
Collaborator

smortex commented Jun 11, 2022

@smortex @chelnak @bastelfreak - why has stdlib been raised to min v8.2.0 in the pull request? That is very high and will have breaking impact when combined with a number of other available modules

Because we had to add escape functions for windows in the stdlib: see this discussion above and puppetlabs/puppetlabs-stdlib#1235.

@chelnak
Copy link
Contributor

chelnak commented Jul 4, 2022

@smortex @bastelfreak How do you both feel about moving forward with this PR?

Pending test failures which I think may be transient, I think it is good.

Though I do wonder if it is a breaking change due to the higher requirements of stdlib.

What are your thoughts?

@chelnak
Copy link
Contributor

chelnak commented Jul 4, 2022

@smortex

I've chatted with @canihavethisone around some of the concerns raised in the comment above.

I personally think stdlib is the right place for the new escape commands however I want to get more of a feel for the potential impact on other users of the module.

This is also an issue that we will probably hit again with other modules. In order to take advantage of newer features in stdlib, the minimum version number will need to be raised.

@canihavethisone
Copy link
Contributor

canihavethisone commented Jul 4, 2022

My concern is that the major fast forward of the stdlib dependency may have significant impact for users of this module in deployments alongside other modules that haven't caught up yet. I recon a good metric would be how many popular modules still have stdlib pinned lower than v.8x, and weigh that against the urgency of this change or if it can be merged when 8x is more commonly scoped. I understand there will be diversity of opinions but think its worth considering.

@neomilium
Copy link
Contributor Author

I recon a good metric would be how many popular modules still have stdlib pinned lower than v.8x, and weigh that against the urgency of this change or if it can be merged when 8x is more commonly scoped.

How to define "popular modules"?

@chelnak chelnak self-requested a review July 11, 2022 08:41
Copy link
Collaborator

@smortex smortex left a comment

Choose a reason for hiding this comment

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

How do you both feel about moving forward with this PR?

My position is that we have tooling to check module versions and that roles and profile in a control-repo are working as expected (e.g. using onceover), so do not worry much about bumping versions. I would not expect users to blindly update things, skipping major versions and assume everything will be fine witout testing :trollface:.

@canihavethisone
Copy link
Contributor

canihavethisone commented Aug 18, 2022

@chelnak @smortex
Hi, im not concerned about people blindly updating, I'm concerned that we will lock out users who use this module alongside numerous others. Locking them out will deny them of new features and bugfixes until their other dependencies support stdlib v8. Bottom line IMO is that there is a huge difference between setting the upper limit to v8 or the lower requirement to v8. Its also a cost v benefit consideration at this moment in v8's youth.

@binford2k
Copy link

Here's a list of all the Forge modules that pin their stdlib dependencies to <8.x, sorted by download count (a weak correlation to popularity.) Notice that many of them are deprecated.

https://docs.google.com/spreadsheets/d/16QT1wd5CmwJL9TbKe4GZgpPi3W4nXHo7Q4fD5aK8bRM/edit#gid=223629225

@LukasAud
Copy link
Contributor

Hi @neomilium. After careful evaluation of your PR, I'm happy to inform you that we are ready to go ahead and merge it. Thanks for your contribution!

We also noted that there are some concerns about this PR, such as the one raised by @canihavethisone. We have considered the potential impact of these changes and we have decided to still go forward with it. While it is true that there may be some compatibility issues with a few non-supported modules, we also have noted that this change may be important for one of our current security enhancement projects and, as such, either this or something very similar was bound to be implemented sooner or later. We are sorry if this causes any inconvenience.

@LukasAud
Copy link
Contributor

This PR will be temporarily reverted until a release can be cut. Then it will be reinstated. This process is done to follow with standard best practices.

@LukasAud
Copy link
Contributor

Hey @neomilium. We are sorry for this inconvenience but we had to revert your PR in order to follow best practices when releasing a new version of our module, by making a minor release prior to a backwards incompatible one. We could re-implement it but I'm afraid it would appear under our name. Could you reopen your branch under a new PR so that we can merge and give proper credit to all contributors?

@kenyon
Copy link
Contributor

kenyon commented Oct 28, 2022

Rebasing or cherry-picking the commits would maintain the original commit authors.

GSPatton added a commit that referenced this pull request Nov 8, 2022
docker_run_flags: Shellescape any provided values
@neomilium neomilium deleted the shellescape branch November 9, 2022 06:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants