The `dcopidlng' script in the KDE library package (kdelibs-3.3.2/dcop/dcopidlng/dcopidlng) creates temporary files in a unsecure manner. This bug has been fixed in 32 minutes (!) by Stephan Kulow, the KDE team leader. Here you can found the official patch: http://bugs.kde.org/show_bug.cgi?id=97608 Note: This bug has been find by `autospec', the work-in-progress tool used by the QiLinux team to (semi)automatically create specfiles from tarballs and update/check rpm packages. It's released under GPL and not QiLinux specific. The latest release can be found at the URL: ftp://ftp.qilinux.it/pub/QiLinux/devel/tools/autospec/
KDE please verify and bump.
Created attachment 51120 [details, diff] alternative solution The fix suggested upstream does not look acceptable, it doesnt solve the issue of predicatable temp files (what if the user executes the script in /tmp?), and it would break if the user ran the script with a working directory they dont have write permissions to. This patch just moves the temp file into ~/ which solves both problems :)
> The fix suggested upstream does not look acceptable, it doesnt solve the > issue of predicatable temp files (what if the user executes the script > in /tmp?) Maybe I'm misunderstanding the security risk here, but I don't see why the upstream fix is problematic. The answer is simply 'don't run it in /tmp'; the Gentoo ebuilds won't, the user shouldn't either. After all, lots of things create predictable or even fixed-named files in the current dir, and we don't consider them to be security problems. All parts of an autotools-based build process use predictable or fixed filenames - run configure in an empty dir for an example. > it would break if the user ran the script with a working directory they dont > have write permissions to. So would all the rest of the kde build process, or any autotools-based build process. Using dcopidlng separately from a standard build environment is rare. As for creating temp files in ~, I really don't like that. If you're a real user (not portage), you don't want to clutter your homedir with temp files that might stick around if the process creating them dies abruptly. Besides, some user accounts have no dedicated homedirs. Creating temp files in ~ wouldn't work if the running account had write access to a dedicated build dir, but its homedir was some place writeable only by root, like a lot of the system-created accounts I see in /etc/passwd. Carsten: you seem to agree with Tavis? Let's resolve this quickly, one way or the other.
> The answer is simply 'don't run it in /tmp'; the Gentoo ebuilds won't, the user shouldn't either. I admit I don't know much about kde, if you think that is an acceptable policy, I'll take your word for it.
I agree we should stick with how upstream does it. KDE team: are you going to apply upstream patch to the currently available releases ?
>Carsten: you seem to agree with Tavis? Let's resolve this quickly, one way or the other. Sorry that I'm coming back to this so late. :( The problem is ideed negligible. I still feel a bit uncomfortable with the possibility to let joe stupid do, what he shouldn't do, though. Afaik there's no good reason for a world writable /tmp. /tmp/~user would do it as well. But this is not specific to this bug. arch herds: I know you love to compile kdelibs to be sure it works fine, but have a look at the patch. Maybe you want to mark it straight stable, this time. ;) <<< kdelibs-3.2.3-r6.ebuild <<< kdelibs-3.3.2-r4.ebuild
Stable on amd64.
Stable on alpha.
Stable on ppc.
stable on the sparc domain.
I know they weren't listed here, but stable on ppc64 per Tom Gall.
Chris: Sorry, my fault. The lines looked the same to me and I took the first. Need to write a better script.
Um, full stop! When I made the patch, I took it from the bug report and not from kde cvs, since it was down. trap missed signals... <<< kdelibs-3.2.3-r7.ebuild <<< kdelibs-3.3.2-r5.ebuild Sorry for that. :(
Arches please test and mark stable.
kde.org just released patches for bug 81110, -rX+1 pending
Forget the above comment, "disclosure" date is March 16.
stable on ppc64
Stable on amd64 again.
Stable on sparc.
GLSA 200503-14 ia64 please remember to mark stable.
I am also having an issue that looks like it could be resolved by this ...how do I apply this patch?
> I am also having an issue that looks like it could be resolved by this ...how do I apply this patch? Just emerge kdelibs-3.3.2-r5
This works, however kdenetwork was unable to emerge following kdelibs-3.3.2-r5. Here's the error: checking for KDE... libraries /usr/kde/3.3/lib, headers /usr/kde/3.3/include checking if UIC has KDE plugins available... no configure: error: you need to install kdelibs first. !!! ERROR: kde-base/kdenetwork-3.3.2 failed. !!! Function kde_src_compile, Line 154, Exitcode 1 !!! died running ./configure, kde_src_compile:configure !!! If you need support, post the topmost build error, NOT this status message. * kde-base/kdelibs Latest version available: 3.3.2-r5 Latest version installed: 3.3.2-r5 So I DO hve kdelibs installed ...it just feels like kdenetwork does not care for the version ...any ideas?
> checking for KDE... libraries /usr/kde/3.3/lib, headers /usr/kde/3.3/include > checking if UIC has KDE plugins available... no > configure: error: you need to install kdelibs first. That's bug 81066
Stable on mips.
Already stable on hppa
