Re: lintian: shlib-read-write-env

[Christian Seiler <christian@iwakd.de>]

On 01/31/2017 04:49 PM, Ben Hutchings wrote:
> On Tue, 2017-01-31 at 14:23 +0100, Christian Seiler wrote:
>> On 01/31/2017 11:15 AM, Mathieu Malaterre wrote:
>>> I'd like to discuss addition of a new lintian checks for
>>> getenv/setenv/putenv used in shared libraries.
>>
>> Why getenv() though? It just reads the environment.
>>> From what you link yourself:
>>> The getenv and secure_getenv functions can be safely used in
>>> multi-threaded programs.
> [...]
> 
> But it returns a pointer to the value, which might be freed by another
> thread before it is used.  If there were a reader function that copied
> the value to a caller-provided buffer, it could be properly thread-
> safe.

But that's only a problem if you call setenv() or similar in a
different thread, which you shouldn't do.

getenv() is only unsafe if the environment is modified, a library
using getenv() in a program that follows libc's guidelines to not
call setenv() in an MT-context is perfectly fine.

(Any program that calls setenv() will call getenv() as well at
some point, otherwise you could simply drop the setenv() completely;
so any program that does that in an MT context is broken anyway,
regardless of whether it uses a library that does an additional
getenv().)

So regardless of whether a check for setenv() etc. in libraries
is introduced into lintian: getenv() shouldn't be checked for
IMHO.

That said: I do agree that the way the entire API around
environment variables is defined is quite horrible.

Regards,
Christian