David Parsley píše v St 14. 11. 2018 v 08:45 -0500: > > On Wed, Nov 14, 2018 at 3:43 AM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote: > > I mean, seriously, people do lots of stuff. It doesn't mean that all > > what people do is actually a good idea or just safe. > > Certainly agreed on this point. It is my belief, however, that system software, where possible, should implement controls to head-off security mistakes of this kind made by those people - like me. Right now I think systemd doesn't go far enough - I was lucky that I saw that warning in the logs, and the contents of my unit file were insecure when I thought it was secured by file permissions. I still believe systemd should refuse to start the service to draw attention to this error in thinking, and that the log entry should probably reference the doc where the not-uncommon practice of putting secrets in environment variables is discouraged - certainly with systemd managed services. > > The practice will continue, however; TravisCI, CircleCI, and my own GopherCI all have mechanisms for providing e.g a GITHUB_PASSWORD environment variable for automated build publishing. No shock that a DevOps engineer might make the mistake of applying the same principle with systemd. I still don't see how that mistake. - Lennart mentions that some of tools that take secrets via environment variables also do so via command line, which is truly insecure. But that doesn't say anything about insecurity of passing secrets via environment variables. - Lennart keeps repeating that passing secrets via environment variable is insecure because they are passed down the process tree. They are, if you choose so in execve(), they are also readable by other processes running under same user from /proc/$PID/environ just like your ~/.bashrc or ~/.netrc. (Don't even start telling me that ~/.netrc is insecure please. Of course it is once you let other users read it.) - Worries about untrusted programs and libraries were mentioned, suggesting that passing secrets via environment variables is insecure, because not all libraries or programs used by the main program could be trusted, completely neglecting the fact that reading environment variable is least worrisome once you let "untrusted" code run as part of it. Give me one solid reason why it's insecure to pass passwords via environment variables please. So far it seems that systemd just broke this concept for no valid reason and now you try to defend with completely unrelated reasons. There were certainly more users expecting that programs sourcing non-world readable environment variables will keep the variables to themselves, than users wanting to check out what environment variables systemd set for its processes. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel