<div dir="ltr"><div class="gmail_quote">On Mon, Feb 13, 2012 at 12:22 PM, Yedidyah Bar-David <span dir="ltr"><<a href="mailto:linux-il@didi.bardavid.org">linux-il@didi.bardavid.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
</div>Indeed, and to strace programs that do this, I do something like that:<br></blockquote><div><br>Thanks! Worked like a charm. Here's the trouble:</div><div><br></div><div><div>[pid 31526] open("$ORIGIN/tls/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div>
<div>[pid 31526] open("$ORIGIN/tls/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>[pid 31526] open("$ORIGIN/tls/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div>
<div>[pid 31526] open("$ORIGIN/tls/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>[pid 31526] open("$ORIGIN/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div>
<div>[pid 31526] open("$ORIGIN/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>[pid 31526] open("$ORIGIN/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div>
<div>[pid 31526] open("$ORIGIN/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div></div><div>... (fallback to other library locations)</div><div><br></div><div>vs a good run of </div><div><div>open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3</div>
<div>open("/usr/lib/gconv/UHC.so", O_RDONLY) = 3</div><div>open("/usr/lib/gconv/tls/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>open("/usr/lib/gconv/tls/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div>
<div>open("/usr/lib/gconv/tls/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>open("/usr/lib/gconv/tls/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>
open("/usr/lib/gconv/i686/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>open("/usr/lib/gconv/i686/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>
open("/usr/lib/gconv/sse2/libKSC.so", O_RDONLY) = -1 ENOENT (No such file or directory)</div><div>open("/usr/lib/gconv/libKSC.so", O_RDONLY) = 3</div></div><div><br></div><div>Some googling lead me to another software having this problem:</div>
<div><br></div><div><pre class="hl" style="background-color:rgb(255,255,255);font-size:10pt;font-family:'Courier New'"><span class="hl lin" style="color:rgb(85,85,85)"> 54 </span><span class="hl ppc" style="color:rgb(0,130,0)">#ifdef SECURE_MAN_UID</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 55 </span> <span class="hl com" style="color:rgb(131,129,131);font-style:italic">/* iconv_open may not work correctly in setuid processes; in GNU</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 56 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * libc, gconv modules may be linked against other gconv modules and</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 57 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * rely on <span class="goog_qs-tidbit goog_qs-tidbit-0 goog_qs-tidbit-hilite" style="display:inline!important;background-color:rgb(255,255,136);color:rgb(0,0,0);text-decoration:inherit">RPATH $ORIGIN to load those modules from the correct</span></span>
<span class="hl lin" style="color:rgb(85,85,85)"> 58 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * <span class="goog_qs-tidbit goog_qs-tidbit-0 goog_qs-tidbit-hilite" style="display:inline!important;background-color:rgb(255,255,136);color:rgb(0,0,0);text-decoration:inherit">path, but $ORIGIN</span> is disabled in setuid processes. It is</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 59 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * impossible to reset libc's idea of setuidness without creating a</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 60 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * whole new process image. Therefore, if the calling process is</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 61 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * setuid, we must drop privileges and execute manconv.</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 62 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> *</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 63 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * If dropping privileges fails, fall through to the in-process</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 64 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> * code, as in some situations it may actually manage to work.</span>
<span class="hl lin" style="color:rgb(85,85,85)"> 65 </span><span class="hl com" style="color:rgb(131,129,131);font-style:italic"> */</span></pre>Alas, <a href="http://neugierig.org/software/blog/2011/04/complexity.html">complexity</a> is indeed a problem.</div>
<div><br></div><div>To make a long story short:</div><div><br></div><div>1) The linux linker let you add to rpath (so search path for a specific binary) the symbol $ORIGIN, which is resolved in runtime to the binaries' path.</div>
<div><br></div><div>2) iconv_open uses this feature to locate additional library at run time (at least in my version).</div><div><br></div><div>3) This feature doesn't work when running suid binaries (at least in my CentOS specific version) for <a href="http://seclists.org/fulldisclosure/2010/Oct/257">security reasons</a>.</div>
<div><br></div><div>4) Thus iconv_open don't find it's library path, assumes that no such encoding exist on the system, and fails with "illegal argument" errno.</div><div><br></div><div>A possible workaround is to create symbolic links to all files in /usr/lib/gconv in the ldd path, enabling iconv to find them even without using the $ORIGIN ldd feature.</div>
<div><br></div><div>For the record, my glibc version is glibc-2.5-49.el5_5.7.</div><div><br></div><div>Thanks!</div></div></div>