On Tue, 13 Nov 2018, David Parsley wrote:
> 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 a bit hesitent to enter this
FWIW Kubernetes also supports mounting files containing secrets, which I've
personally found to be easier to work with than environment variables.
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
On Tue, Nov 13, 2018, 11:20 PM Tomasz
On Wed, Nov 14, 2018 at 02:17:02AM +0100, Marek Howard wrote:
> Marek Howard píše v St 14. 11. 2018 v 01:35 +0100:
> > Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> > > On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> > > Well, you are of course welcome to ignore
Am 14.11.18 um 02:17 schrieb Marek Howard:
>> It's quite handy way to pass secrets and as I said above, there's
>> really no risk if it's done in cases where it makes sense. Of course
>> systemd leaking it to everyone makes it not usable with systemd, but
>> that's not really a problem with
Marek Howard píše v St 14. 11. 2018 v 01:35 +0100:
> Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> > On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> > Well, you are of course welcome to ignore whatever I say, but again,
> > environment blocks are leaky, they
Lennart Poettering píše v Út 13. 11. 2018 v 15:17 +0100:
> On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
>
> > I disagree; privacy of environment variables to individual users on the
> > system is as fundamental as Unix file permissions. If a privileged process
> > (systemd)
On Di, 13.11.18 12:55, Kenneth Porter (sh...@sewingwitch.com) wrote:
> The Unit file documentation should also discourage putting secrets in those
> files.
True. Here's the PR:
https://github.com/systemd/systemd/pull/10764
Lennart
--
Lennart Poettering, Red Hat
--On Tuesday, November 13, 2018 6:59 PM +0100 Lennart Poettering
wrote:
Maybe following "random articles" blindly is not really the best
approach to computer security...
OTOH, most of us learned from reading the writings of others in the
industry. So perhaps the wisdom of this thread
El 13-11-2018 a las 9:49, David Parsley escribió:
I disagree; privacy of environment variables to individual users on the
system is as fundamental as Unix file permissions.
Please find us ONE reference to a relevant, current *nix standard that
says environment variables are either secret,
On Di, 13.11.18 07:49, David Parsley (pars...@linuxjedi.org) wrote:
> I disagree; privacy of environment variables to individual users on the
> system is as fundamental as Unix file permissions. If a privileged process
> (systemd) is configured to start a service and provide environment
>
I disagree; privacy of environment variables to individual users on the
system is as fundamental as Unix file permissions. If a privileged process
(systemd) is configured to start a service and provide environment
variables to an unprivileged service account, it is a reasonable
expectation that
Folks,
I was trying to enable DNS over TLS via systemd-resolved. I've edited
/etc/systemd/resolved.conf as follows:
[Resolve]
DNS=1.1.1.1
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=opportunistic
#Cache=yes
#DNSStubListener=yes
while monitoring the network (with
Folks,
I'm running a Ubuntu 18.10 with systemd 239. I've edited
/etc/systemd/resolved.conf as:
[Resolve]
DNS=1.1.1.1
#FallbackDNS=
Domains=~.
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
DNSOverTLS=opportunistic
#Cache=yes
#DNSStubListener=yes
Still, when running tcpdump it seems systemd-resolved
Hi guys
Apologies for the off-topic question but is tldp.org working for you
or do you know what's going on with it?
I always considered tldp.org a prominent website so I'm surprised to
see it disappear quietly into the night...
___
systemd-devel
On Mo, 12.11.18 19:53, aleivag (alei...@gmail.com) wrote:
> 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
On Mo, 12.11.18 17:41, aleivag (alei...@gmail.com) wrote:
> 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
Don't do this. This is only partially
On Mo, 12.11.18 14:49, David Parsley (pars...@linuxjedi.org) wrote:
> It's a fairly common practice to configure services and provide secrets
> with environment variables.
Passing secrets through env vars is marginally better than passing
them in via cmdline params, but still bad, bad, bad
17 matches
Mail list logo
