minor fix for LD_LIBRARY_PATH setuid detection.

[Martin Buchholz]

See also Kumar's fix
6367077 : Purge LD_LIBRARY_PATH from the Unix launchers
on core-libs-dev

Martin

On Tue, Nov 24, 2009 at 12:32, Christos Zoulas <christos at zoulas.com> wrote:
>
> For BSD it is more appropriate to (Greg feel free to commit this since I can't):
>
> diff -r d6e9dd8952b4 src/os/bsd/launcher/java_md.c
> --- a/src/os/bsd/launcher/java_md.c     Tue Nov 17 08:32:33 2009 -0500
> +++ b/src/os/bsd/launcher/java_md.c     Tue Nov 24 15:20:02 2009 -0500
> @@ -479,7 +479,7 @@
>        * return from the function now.  Getting the right libraries to
>        * be found must be handled through other mechanisms.
>        */
> -      if((getgid() != getegid()) || (getuid() != geteuid()) ) {
> +      if(issetugid()) {
>         return;
>       }
>  #endif
>
> but really the way that the infinite loop of re-execing the launcher
> when LD_LIBRARY_PATH is not set, is a horrible hack that breaks in
> many different ways. The code is similar for linux, and it does
> not work correctly there either, because __libc_enable_secure (the
> variable in the dynamic linker that determines if the binary is
> going to be run in secure mode), is also set when the binary has
> capabilities, and the java code ignores that. I think we need
> something more robust to prevent this infinite loop, such as setting
> a different environment variable to indicate that we tried to exec
> already, or pass a different command line argument. Just depending
> on LD_LIBRARY_PATH being set is too fragile.
>
> christos
>
>