tags 679323 + fixed-upstream stop -----
Will be fixed in man-pages-4.04. See commit c66649c83598652222ff2a464e5b82284e6b1acf by Michael Kerrisk <mtk.manpa...@gmail.com>, 2016-02-19 12:04:51 (GMT) https://git.kernel.org/cgit/docs/man-pages/man-pages.git/commit/man3/clearenv.3?id=c66649c83598652222ff2a464e5b82284e6b1acf ----- Matt Zimmerman <m...@debian.org> a écrit : > On Fri, Feb 19, 2016 at 12:59:05PM +0100, Michael Kerrisk (man-pages) wrote: > > On 18 February 2016 at 21:34, Matt Zimmerman <m...@debian.org> wrote: > > > Thanks for following up. My recommendation is to say something like: > > > > > > This function DOES NOT securely erase the contents of the environment. > > > Security-conscious applications which need to do this should use .... > > > instead. > > > > So, I think this report is a little confused, but mainly because of > > the poor description in the man page. > > > > The security-conscious applications in this context are those that > > want to precisely control the environment passed to an exec()ed > > program. clearenv() cannot, indeed must not, try to erase the buffers > > containing the environment definitions. (See putenv(3) to understand > > why.) I've adjusted the man page in away that I hope explains things > > better: > > > > The clearenv() function may be useful in security-conscious > > applications that want to precisely control the environment that > > is passed to programs executed using exec(3). The application > > would do this by first clearing the environment and then adding > > select environment variables. > > > > Note that the main effect of clearenv() is to adjust the value of > > the pointer environ(7); this function does not erase the contents > > of the buffers containing the environment definitions. > > Yes, that's much clearer, thank you! Case classified, thank you for your help Matt and Michael! Regards, -- Stéphane Aulery
