If you use EnvironmentFile the only thing a user could do is systemctl
show, and that will tell them that what environment file was used , but not
it's content...
As long as you unset the env, you should be fine (but I'm not a expert on
this)
El lun., 12 de noviembre de 2018 7:18 p. m., David Pa
I already scrub the environment when executing external scripts, and I've
found that even after os.Unsetenv(...) the full environment is available to
all processes owned by the robot in /proc//environ. I'm fleshing out a
solution where the process consumes the environment then scrubs it from
proc w
hi Reindl: I was protecting against "systemctl cat/show" disclosure of
information, as stated in the question; but i agree with you, and there are
always risk in passing credential in env variables, but you can always try
to mitigate them (e.g. the main process can read the variables and then
remov
Am 12.11.18 um 21:41 schrieb aleivag:
> You can define those secrets on /etc/robotsecret.txt, and then on your
> unit you do `EnvironmentFile=/etc/robotsecret.txt`
>
> then you protect /etc/robotsecret.txt as you would normally do
and how does that protect anything?
on a webserver running php
You can define those secrets on /etc/robotsecret.txt, and then on your unit
you do `EnvironmentFile=/etc/robotsecret.txt`
then you protect /etc/robotsecret.txt as you would normally do
Alvaro Leiva Geisse
On Mon, Nov 12, 2018 at 4:49 PM David Parsley wrote:
> It's a fairly common practice to
It's a fairly common practice to configure services and provide secrets
with environment variables. For instance, both Hubot (made by Github) and
Gopherbot (made by me) can get their Slack token from an environment
variable. In my case, github.com/lnxjedi/ansible-role-gopherbot stores the
Slack bot
