[VDPAU] [PATCH] Save the result from secure_getenv
Zach Angold
zangold at nvidia.com
Wed Feb 17 22:51:14 UTC 2016
Thanks for your input, but there seems to be another way we can lose
the result from secure_getenv.
>From the man page for getenv(3):
The implementation of getenv() is not required to be reentrant.
The string pointed to by the return value of getenv() may be
statically allocated, and can be modified by a subsequent call
to getenv(), putenv(3), setenv(3), or unsetenv(3).
In theory we could run into problems with this since (without this
patch) we use the return value of secure_getenv("VDPAU_DRIVER") after
calling secure_getenv("VDPAU_DRIVER_PATH"). Replacing the other two
occurrences of secure_getenv with safe_secure_getenv has no functional
impact on libvdpau as it is, but it could prevent problems like this
in the future.
--
Zach Angold
On Wednesday 17 February 2016 00:22:58 +0200 Rémi Denis-Courmont wrote:
> From: Rémi Denis-Courmont <remi at remlab.net>
> To: vdpau at lists.freedesktop.org
> Subject: Re: [VDPAU] [PATCH] Save the result from secure_getenv
> Message-ID: <42814383.FrDi8JCZNQ at basile.remlab.net>
> Content-Type: text/plain; charset="utf-8"
>
> On Tuesday 16 February 2016 14:18:14 Zach Angold wrote:
> > The return value from secure_getenv is not guaranteed to be kept after
> > another call to secure_getenv,
>
> AFAIK, it can only "change" if the environment changes. Changing the process
> environment should only be done early in main().
>
> If other threads already exists, it´s undefined behaviour anyway. If libraries
> (e.g. VDPAU) are already initialized, it´s likewise calling for big troubles.
>
> So I don´t really see the point in this patch. If you fear that the
> environment changes, you need atomic access to the environment. And that´s
> essentially not possible with POSIX :-(
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
More information about the VDPAU
mailing list