99designs / aws-vault

I am using the latest release of AWS Vault
I have provided my .aws/config (redacted if necessary)
I have provided the debug output using aws-vault --debug (redacted if necessary)

Currently, aws-vault does not have "entrypoint" for exec command - a default shell used for executing command.

This causes issues on some situations. For example, pipe (|) and redirect (>) cannot be used directly because these features are not supported by syscall.

This causes issues on Windows machine as well. In my case, I had to type this long command:

aws-vault exec <username> "--" powershell "CMD"

The reason I have to double quote CMD is because otherwise variables quoted by $() will be expanded before executing the problem. And I can't double quote powershell because aws-vault uses the first argument as syscall executable (which does not include space and arguments).

This is quite annoying and takes some time to know what's going on. Especially now that AWS tools requires Powershell , the problem will start to affect more and more.

To tackle this issue, We can add "entrypoint" feature, just like Docker. Users now have the ability to decide which shell they want to use, and the settings will be used on aws-vault exec command.

For Windows, the entrypoint can simply be

powershell

And for Linux,

/bin/sh -c

should be used.

For example, pipe (|) and redirect (>) cannot be used directly because these features are not supported by syscall

Can you provide an example of this?

For example, pipe (|) and redirect (>) cannot be used directly because these features are not supported by syscall

Can you provide an example of this?

aws-vault exec <profile> -- ./<exe_file> "> test 2>&1"

aws-vault exec <profile> -- "./<exe_file> > test 2>&1" (doesn't even run at least on Windows)

We have to avoid this issue by

aws-vault exec <profile> -- ./<exe_file> > test 2>&1 (not ideal when "--debug" flag is on, because stderr will be dirty)

or

aws-vault exec <profile> -- </bin/sh | powershell> "./<exe_file> > test 2>&1"

aws-vault exec <profile> -- ./<exe_file> "> test 2>&1"

Why is the redirect quoted - does the following not work?

aws-vault exec <profile> -- ./<exe_file> > test 2>&1

(not ideal when "--debug" flag is on, because stderr will be dirty)

But why would --debug be used in conjunction with a redirect? That flag should only be necessary when debugging aws-vault itself

Thank you for your response. 😃

aws-vault exec <profile> -- ./<exe_file> "> test 2>&1"
Why is the redirect quoted

I posted this as an wrong example that doesn't work.

Does the following not work?
aws-vault exec <profile> -- ./<exe_file> > test 2>&1
(not ideal when "--debug" flag is on, because stderr will be dirty)

But why would --debug be used in conjunction with a redirect? That flag should only be necessary when debugging aws-vault itself

When MFA is enabled users will be asked to enter their MFA code. so redirecting can still cause problems even when "--debug" flag is not set.

Yeah if mfa is required, it's essentially an interactive terminal. There are 2 possible approaches to this

use --mfa-token to keep the command non-interactive
use a subshell with aws-vault exec PROFILE and then run your command with the redirect

But yes I take your point that it's not ideal in that scenario. I'll think about this a bit more

This scenario has now been addressed in #1149

If aws-vault encounters a non-tty, it will attempt to use an alternative MFA prompt automatically.

For example, this command results in GUI prompt for MFA

$ aws-vault exec role-wth-mfa-prompt -- echo woot > test.log 2>&1

@Toshimichi0915 does this resolve the issue for you?

It solved most of the addressed issues but I want default shell to be customizable; I want to use powershell instead of cmd.exe, which I think makes "entrypoint" feature request still valid

@Toshimichi0915 there is no default shell. AWS vault is exec-ing without a shell

@Toshimichi0915 there is no default shell. AWS vault is exec-ing without a shell

aws-vault/cli/exec.go

Line 309 in ba79e47

command = "cmd.exe"

Also, why don't default shell exist when commands are specified?

PS C:\Users\main\Desktop\projects\aws-vault> .\aws-vault.exe exec <hidden> echo "Hello, world"
Enter MFA code for arn:aws:iam::<hidden>:mfa/<hidden>: <hidden>
aws-vault: error: exec: exec: "echo": executable file not found in %PATH%

I can't execute this command for example because echo isn't executable, and is rather a part of cmd.exe/powershell

That exec.go default shell is only used to create a subshell. It's used when a command isn't specified

I can't execute this command for example because echo isn't executable, and is rather a part of cmd.exe/powershell

Correct. aws-vault exec PROFILE cmd.exe echo "Hello, world" might be the way to execute a shell script (but i'm not a windows expert).

which I think makes "entrypoint" feature request still valid

Don't get me wrong, I agree that this could be a legitimate feature. The question to me is whether this is a "necessary" feature. Any feature added creates new complexity. At the moment it seems there are simple-enough alternatives vs adding a new mode of execution

While this is an interesting feature, it's questionable whether this is a necessary feature. Any feature added creates new complexity and maintenance burden. At the moment it seems there are simple-enough alternatives vs adding a whole new mode of execution.

Add "entrypoint" feature