cyberark / summon

CLI that provides on-demand secrets access for common DevOps tools
https://cyberark.github.io/summon
MIT License
705 stars 63 forks source link

Summon does not correctly load input provider path on Windows #167

Closed izgeri closed 4 years ago

izgeri commented 4 years ago

Summary

From Discourse post:

I have a problem in use Summon with a non-standard path to conjur provider.

When I use provider path for example: "C:\Program Files\Cyberark Conjur\Summon\Providers\conjur" provider interprets this patch as "C:\Program Files/Cyberark Conjur/Summon/Providers/C:\Program Files\Cyberark Conjur\Summon\Providers\conjur" which is absolutely mess up path

Input:

PS C:\Users\marcin.dzieciol> C:\Users\marcin.dzieciol\Downloads\summon.exe -p "C:\Program Files\Cyberark Conjur\Summon\Providers\conjur" --yaml 'pass: !var pass' powershell .\pass.ps1

Output:

CreateFile C:\Program Files/Cyberark Conjur/Summon/Providers/C:\Program Files\Cyberark Conjur\Summon\Providers\conjur: The filename, directory name, or volume label syntax is incorrect.

It seems to be a problem with the hardcoded path for the Windows version of the application. Can you resolve a problem with a broken path? I need to use custom path in my infrastructure.

Reproducible

Version/Tag number

Unknown

Environment setup

Unknown

Additional Information

n/a

izgeri commented 4 years ago

Related to #87

sgnn7 commented 4 years ago

I think support for absolute paths for --provider was not historically supported on ether platforms but it's probably a feature we can add. If a workaround is needed a softlink/hardlink from provider_default_dir or current_dir to the plugin should be able to work around it until we fix this.

CC: @mdzieciol

izgeri commented 4 years ago

@sgnn7 can you please share more info? It sounds like you are suggesting that a relative path should be used for the --provider flag, but in the flags documentation it says:

specify the path to the provider summon should use. If the provider is in the default path,/usr/local/lib/summon/ you can just provide the name of the executable. If not, use a full path.

That snippet seems to indicate that absolute paths are supported, and in fact are required if the provider is not in the default path.

Also, the default path given in the flag docs is the default path for non-Windows OSes - based on the initial bug report, it appears that the default Windows provider path is C:\Program Files/Cyberark Conjur/Summon/Providers/. Should the docs be updated with this info?

sgnn7 commented 4 years ago

@izgeri Hmm I was not aware of this and if we do support this, it may have been using some implicit logic to do it. I can take a look at seeing how fixable this is soon.

mdzieciol commented 4 years ago

Thank you for creating this topic @izgeri
I'm on holiday and I didn't follow this topic until now. @sgnn7 If you have any additional questions, I'll be at work on Monday and I'll be able to test something for you.

sgnn7 commented 4 years ago

So while working on this I found that a full path can be provided but you have to use universal path separators (/):

summon.exe -p "C:/Program Files/Cyberark Conjur/Summon/Providers/conjur" `
  --yaml 'pass: !var pass' `
  powershell .\pass.ps1`

I will still try to get this fixed up though to be able to support both.

sgnn7 commented 4 years ago

Fix PR is merged and the fix is queued for 0.8.3 release.

sgnn7 commented 4 years ago

Closed via v0.8.3 release: https://github.com/cyberark/summon/releases/tag/v0.8.3