Re: [trinity-devel] kdelibs potential security vulnerability

Hello, The kdelibs/qt3 combination I built (from the stable sources) has a security hole: when the dynamic loader loads libkdecore.so, the libmng.so.1 is first searched in a directory in /tmp, which could potentially result in a local root privilege escalation if there are suid binaries which depend on kdelibs on the target system. Even without suid binaries, on a multi-user system one could gain another user's privileges by letting them load a kdelibs-using binary while a forged libmng is present in the /tmp directory (and usually can't be deleted by a regular user because of the sticky bit in /tmp). The build script I use does $ export LD_LIBRARY_PATH=$TMP/build-qt3/qt3/lib:$LD_LIBRARY_PATH (actually Calvin Morrison's PKGBUILD does the same thing). Perhaps this hack has a relation with the issue, but anyway Patrick Volderking (the creator of Slackware) mentions in his old build script for Qt3 (when KDE3 was in Slackware) that building Qt3 in /tmp gives ****, and his script builds qt3 directly on $PREFIX/lib{,64}/qt (or qt3, depending on the exact script). But I'm not sure this is compatible with all distribution policies… as another means of avoiding /tmp, the gcc Slackware build scripts which use /$(mcookie) as a temporary directory. Are official binaries affected by the issue ? I don't know Debian/Red Hat building procedures at all and then I have no idea of the answer.