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

Environment variables interface #67

Closed
robert-cronin opened this issue Aug 11, 2020 · 3 comments · Fixed by #73
Closed

Environment variables interface #67

robert-cronin opened this issue Aug 11, 2020 · 3 comments · Fixed by #73
Assignees
Labels
development Standard development
Milestone

Comments

@robert-cronin
Copy link
Contributor

robert-cronin commented Aug 11, 2020

Environment Variables

So to give an example of environment variables.

In any Unix shell you can set environment variables:

x=3
echo "$x"

You can expose these variables to subprograms:

export x=3
echo "$x"
bash -c 'echo "$x"'

However subprograms CANNOT set environment variables in the parent process. Which is the current shell.

So how would polykey help in the process of setting environment variables?

There are 2 ways:

  1. Is for the pk command to spit out instructions to set environment variables in the shell. This requires the user to copy the command. This I've seen in other programs, but it's not really a nice UX.
  2. Is to do what env does. The env command basically is a "fork+exec" at the shell-level but with the additional ability to set environment variables.

Let's explore 2.

To do 2. it is possible to not even use env at all.

x=3 bash -c 'echo "$x"'

This ensures that the environment variable is set for only the subprocess. And it does not export it to every other subprocess. This is good because of principle of least privilege.

So why use env? It is because it has lot of extra options to deal with environment variable manipulation and also signal manipulation and also dealing multi-parameter shebangs.

So how does this apply to Polykey?

The second way for Polykey to interface via environment variables is to expose an env like interface.

Suppose I wanted to pass some secret into some program that uses environment variables.

I could run it with polykey like this.

pk secrets get K --run 'bash -c "echo $K"'

The above basically "chains" the secret coming out of polykey directly injecting as an environment variable into the command in --run.

See nix-shell for examples of this. The nix-shell has [--command cmd] [--run cmd]. The first is an expression of a shell command. The second is the ACTUAL program being executed. So --run should be equivalent to doing a execvp. Whereas --command should be equivalent to a execv. See: https://stackoverflow.com/a/20823413. So the main difference is that --command runs in the "shell", whereas --run runs the actual program.

So this would mean that we are embedding the ability to do env-like functionality inside the pk commands. However it isn't entirely necessary. It is possible to allow the user to do command substitution.

K="$(pk secrets get K)" bash -c 'echo "$K"'

However... we should probably care about UX, so let's add the ability to "run" something with a given context. But it should probably not be done in the trivial way I just explained above.

To deal with more complex cases, it may be better to have some "chording" interface. This means almost a small kind of APL-like language in the pk commandline. So you can do things like pk secrets get K, get Y, get C... etc.

There are so many possible ways to organize/format the output. The best way to do so, is think of it as an language or "formatting" language. So you could spit out JSON, you could spit environment variable setters:

K='3' Y='4' C='5'

And many possible others.

The point is, this is the "env" variable interface.

@CMCDragonkai
Copy link
Member

For GUI, to do env variable injection, you would need to fork and exec and then make sure the process is inherited by X. Sort of like dmenu. You don't want Polykey to act like a process manager so you don't want to be the parent to all these processes.

Not sure how to do it exactly, but I know dmenu program does this. It is a graphical launcher.

Windows is likely different again.

Is it possible through electron?

Recommend looking at dmenu's source code.

@robert-cronin
Copy link
Contributor Author

I wasn't even thinking about environment variable injection by the GUI, how would it work? I guess you could have polykey-gui open the standard terminal with the environment variables injected in? Or are you thinking something more for triggering other GUIs from polykey-gui with env var injection that way?

I am not too familiar with dmenu :D perhaps it offers this capability

@robert-cronin
Copy link
Contributor Author

From discussion, it looks like, at least for UNIX systems, double fork+exec is sufficient to launch a GUI program with environment variable injection. This is what happens from the application launcher anyway. Any apps launched this way become orphaned and picked up again by systemd. If they are launched by a terminal, they become child processes of that terminal process.

So in this way, polykey can become a sort of alternative application launcher with integrated environment variable injection.

The only issue is, environment variables are rarely used this way by GUI programs, so this feature is probably of low priority.

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

Successfully merging a pull request may close this issue.

2 participants