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 it's just a one-liner to get $_ENV which is why sensitive data don't belong there and should never exposed that way like passwords in teh commandline are plain wrong > On Mon, Nov 12, 2018 at 4:49 PM David Parsley <parsley@xxxxxxxxxxxxx > <mailto:parsley@xxxxxxxxxxxxx>> wrote: > > 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 > <http://github.com/lnxjedi/ansible-role-gopherbot> stores the Slack > bot token with "Environtment=GOPHER_SLACK_TOKEN=xxx" in the systemd > unit file. I had hoped to keep this info to the robot user by > marking the unit file world-inaccessible. I was dismayed to see the > log warning about values being accessible via the API, though super > glad that my unprivileged user couldn't fetch it with a > simple |systemctl cat gopherbot|. I know very little about DBUS or > any APIs for systemd, so wanted to ask - is there some means by > which a non-privileged user can access the values provided with > "Environment=..." lines? Can I disable this by disabling dbus-daemon > on server systems? _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel