On Sat, 24.01.15 14:20, Sangjung Woo ([email protected]) wrote: > According to the glibc manual, secure_getenv() is more trustful than > getenv() since it returns a null pointer if the environment is untrusted > such as setting SUID or SGID bits. Moreover, libraries should use > secure_getenv(). > (http://www.gnu.org/software/libc/manual/html_node/Environment-Access.html)
Well, but these functions are pretty much just wrappers around these env vars, and that's documented in the man pages, pretty clearly. Or in other words: if you invoke sd_listen_fds(), you do so precisely to get the values derived from the env vars back, and this is even validated via $LISTEN_PID. You get the stuff that was passed to you via activation, and you invoke it only on activation, and you know that you do. The recommendations of the glibc manual are good recommendations, but I don't think they apply here. I mean, this stuff is pretty explicit, and just about querying stuff that is derived from these env vars, it does not much else. If this was a library that does some background stuff, some stuff that is not immediately obvious from the API the original app developer used, then sure, using secure_getenv() sounds appropriate, because the developer might not be aware of what is going on there. Note that we use secure_getenv() pretty much everywhere else in systemd already, however sd_listen_fds() and friends are a very different cases... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
