Re: Matlab & LD_LIBRARY_PATH




--- Matthew Saltzman <mjs@xxxxxxxxxxxxxxx> wrote:

On Thu, 3 Aug 2006, Matthew Miller wrote:

On Wed, Aug 02, 2006 at 11:48:49PM -0400, David Scriven wrote:
One can set LD_LIBRARY_PATH manually - ie. from the prompt
and things work fine.

My guess that somewhere it is being UNSET, but I can't figure
out where. This happens on different machines running either
FC4 or FC5.

Something must be "sanitizing" it for security reasons.
Interesting.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164869

I recall running into this sometime around RH9. I thought I had
filed a
bug, but I can't find it now. I did find this, though:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118262

And I wonder if the conclusion is relevant:

Comment #3 From Jason Vas Dias:
This bug is blocked by glibc bug 129682 - no setuid/setgid program
can obtain LD_LIBRARY_PATH from the environment of a non-owner
invoking user.

at could be converted to not require setuid/setgid bits to be set
-
will work on this for next at version.

Comment #4 From Jason Vas Dias:
It seems the glibc developers consider this not a bug,
but a security feature that is unlikely to be changed.
So you'll just have to set LD_LIBRARY_PATH manually
in your at jobs - it won't be recorded from your
invoking environment if you are not root.

For the reader's convenience:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129682

The question is, when logging in via the display manager, does
something
setuid/setgid get run after .bash_profile? Then, is there some
startup
script that gets run after that program that could set the
environment?

In my experience, logging in not via the display manager results in
LD_LIBRARY_PATH being set from .bash_profile as expected.

--
Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list


Hi Matthew,

There is a work-around - put it in /etc/bashrc and LD_LIBRARY_PATH
is set. Not optimal, but it works!

As far as setting it via /etc/profile - you are correct - booting
into a console (init 3) allows LD_LIBRARY_PATH to be set. Further
if you 'startx' LD_LIBRARY_PATH will still be set in whatever
display manager you are using.

However booting into X11 (init 5) prevents LD_LIBRARY_PATH from
being set.

The fact that you can legimately set it (init 3) would argue
against it being a security issue - it seems to be a mystery
that only people with greater knowledge than I can solve.

DS


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list



Relevant Pages

  • Re: [BUG] get_rtc_time() triggers NMI watchdog in hpet_rtc_interrupt()
    ... but occasionally also early in init. ... The bug may not originate from the 2.6.27-rc series as I only recently ... enabled HPET in this machine's kernels (not due to HPET problems, ... I also just got this during shutdown: ...
    (Linux-Kernel)
  • Re: Bug? in SUSE 9.2 console or init 3 windows button
    ... Was garbled sys info and system state. ... init 3 keeps you from being stuck in an annoying graphic boot. ... The bug is for the install to default to graphic boot. ...
    (alt.os.linux.suse)
  • 2.6.0-test6: more __init bugs
    ... Here are some cases where __init code or data is referenced by ... Ditto for Scsi_Host_Template.detect? ... ** Probably a bug: ... Fix: ...
    (Linux-Kernel)
  • Re: Signal delivery to kernel threads/processes?
    ... >> Another possible interpretation, not quite the same, might be to use ... to add insult to injury by following up to my post yet another time: ... Setting P_SYSTEM for init is a bug. ...
    (freebsd-arch)
  • Re: sshd exploit
    ... ::> to a bug which has not yet been announced. ... :: machines running both 2.5.x and 2.9.x versions of OpenSSH were indeed ... :: compromised while running ssh version 1. ... reports I've read, including the long, detailed message sent by the ...
    (FreeBSD-Security)