`safe --target target` sometimes makes sense

[dennisjbell]

Obviously, safe --target <x> target doesn't make a lot of sense on its own, but there are conditions where it does make sense.

The most crucial is when the safe target is being specified by the SAFE_TARGET environment variable. In this case, safe outright lies to you when you run safe target because internally, there is no difference between overriding the target with --target or by use of the environment variable.

The scenario:

$ export SAFE_TARGET=prod
...some time later...
$ safe target sandbox
$ safe target

Specifying --target to the target command makes no sense; ignoring...
Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox

$ safe rm -rf secret/*
# Oh-noes - prod secrets all gone!

In this case, safe target should return whatever target will be used when safe is called in that environment.

Similarly, when running safe target --json in order to get the current target information in a json format, safe currently gives the .saferc 'current' target details, not the target in that environment. It even makes more sense to support the explicit --target <x> option in this case for when you want to read details about a specific target without changing the actual target.

[jhunt]

Bear in mind that fixing this doesn't magically make the implicit target TOCTOU race condition check go away, with respect to rm.

A scenario that is still dangerous:

me@term1 $ safe target sandbox
me@term1 $ safe target

Currently targeting sandbox at https://10.10.0.4
Skipping TLS certificate validation
Uses Strongbox at http://10.10.0.4:8484/strongbox

... switch to another terminal, same box ...
me@term2 $ safe target production

... switch back to where it says i'm targeting sandbox ...
me@term1 $ safe rm -rf secret/*
# oh noes!! where my prod secrets at?!

[tofds]

We are facing the same impediment working with various vaults. Especially switching between terminals pointing to different vaults may result in lost or misdirected secrets, as jhunt pointed out.

I can either use "safe target " in my shell, OR use "export SAFE_TARGET="" ", but mixing them appears to be a bad idea. But unless we remove the ~/.saferc there is no way to UNSET the "safe target".

The goal would be to be able to work with various shells, each pointing to a separate vault without the shells affecting each other.

[umutkacar]

I share the concerns stated above. Please make safe, "safe" to operate against separate Vault instances on different terminal panes.