You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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
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.
Environment Variables
So to give an example of environment variables.
In any Unix shell you can set environment variables:
You can expose these variables to subprograms:
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:
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.env
does. Theenv
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.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.
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. Thenix-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 aexecvp
. Whereas--command
should be equivalent to aexecv
. 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.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 likepk 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:
And many possible others.
The point is, this is the "env" variable interface.
The text was updated successfully, but these errors were encountered: