21–30 of 38 posts
On most modern Mac OS installations, this is a non-issue. System Integrity Protection doesn't honor any changes to LD_LIBRARY_PATH, presumably for exactly this sort of reason. (Of course, one might have turned off SIP, in which case this is no longer true, but it's nice to know it's the default).
Buried in there is "Torch machine learning library", which then allowed me to figure out what software was being blamed. http://torch.ch/
At least you didn't read "ls " as "is" with a capital "i"...I only read it it to un-confuse myself!
What's wrong with something like, "Torch machine learning introduces vulnerability in loading of shared libraries." Whilst it doesn't tell the whole story it does at least give a flavour instead of just sowing confusion.
More concerning to me is that ld.so will interpret a trailing `:` in LD_LIBRARY_PATH to mean to include PWD. Where is this documented? It's not indicated in ld.so's manpage: http://man7.org/linux/man-pages/man8/ld.so.8.html Sounds like a bug in GNU's ld.so more than anything.
It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading colons, adjacent colons).
This de facto standard becomes a little more obvious when one considers a likely implementation (iterating over "strchr(arg, ':')" or whatever). Any of these sequences then will give up an empty string:
PATH=:/foo
PATH=/foo:
PATH=/foo::/bar
zwp:/tmp$ cd ''
zwp:/tmp$ pwd
/tmp
zwp:/tmp$
I agree it's surprising and potentially dangerous.
FWIW, the execp() functions hide a similar wtf. From the Linux man page:
The file is sought in the colon-separated list of
directory pathnames specified in the PATH envi‐
ronment variable. If this variable isn't defined,
the path list defaults to the current directory
followed by the list of directories returned by
confstr(_CS_PATH).
Seems like this may almost have been better done through a disclosure channel with torch?
Torch probably doesn't even need to set LD_LIBRARY_PATH. If LD_LIBRARY_PATH is only being set so that binaries distributed by torch work, then I'd strongly suggest they use RUNPATH instead with $ORIGIN. There are examples in various places: https://enchildfone.wordpress.com/2010/03/23/a-description-o... http://man7.org/linux/man-pages/man8/ld.so.8.html http://longwei.github.io/rpath_origin/ LD_LIBRARY_PATH is really…
Earlier quoted context omitted.
At least you didn't read "ls " as "is" with a capital "i"...I only read it it to un-confuse myself!
Same. I was irritated enough by the badly formed headline to read the story to try and figure out what was going on. What's wrong with something like, "Torch machine learning introduces vulnerability in loading of shared libraries." Whilst it doesn't tell the whole story it does at least give a flavour instead of just sowing confusion.
Torch probably doesn't even need to set LD_LIBRARY_PATH. If LD_LIBRARY_PATH is only being set so that binaries distributed by torch work, then I'd strongly suggest they use RUNPATH instead with $ORIGIN. There are examples in various places: https://enchildfone.wordpress.com/2010/03/23/a-description-o... http://man7.org/linux/man-pages/man8/ld.so.8.html http://longwei.github.io/rpath_origin/ LD_LIBRARY_PATH is really…
This nice and clean solution is too little known I think. Far better than shipping shell scripts which are very hard to get right and most application developers are not shell scripting experts.