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 > variables to an unprivileged service account, it is a reasonable > expectation that said environment is only available to root and the service > account (and it's child processes), and not other arbitrary > users/processes. From a system security engineering perspective, it would > be better if systemd didn't start a service at all with 0600 on the unit > file, rather than violate the principle of Unix environment privacy, and in > fact should actually just check the world-read bit.
Well, you are of course welcome to ignore whatever I say, but again, environment blocks are leaky, they propagate down the process tree, and are *not* generally understood as being secret. You appear dead set on using env vars for this. It's a very bad choice however, it's a pity you ignore comments that don't fit in your view of the world though. Note that even docker got this right, and their "docker secrets" feature, stores them in a file, not in an env var: https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets I mean, there's a lot to complain in what Docker does, but the way it looks, at least that they did get right... > Thanks aleivag; "systemctl show" was what I was looking for; unprivileged, > I was able to see the "Environment=" values, but not the contents of > /etc/gopherbot.env. I'm going to go ahead and update the Ansible role to > operate that way. Urks. I really don't hope this catches on. You are doing it wrong. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
