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 <chris...@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
>
>
