Description of problem:
aRts and kdelibs3 each use their own copy of the same "lnusertemp" code to create a user-specific socket directory for IPC.  If the usual location, which is well-known, is unavailable, a random directory name is created with mktemp(3).  A malicious process could therefore create the well-known location to force the race condition inherit in mktemp(3), and then potentially beat it in order to hijack the IPC of aRts and/or KDE.

Version-Release number of selected component (if applicable):
arts-1.5.10-26.fc22.x86_64
kdelibs3-3.5.10-68.fc22.x86_64
(I believe all versions of Fedora are affected, as well as RHEL 5 and 6)

Steps to Reproduce:
(Warning: Do NOT try this during a KDE session!)
0. KSOCKETDIR=/tmp/ksocket-`id -un`
1. rm -f ~/.kde/socket-$HOSTNAME # (not strictly necessary but does cause this to be logged with 'artsd -l 0')
2. rm -fr $KSOCKETDIR && touch $KSOCKETDIR
OR: su -c "mkdir -m 0700 $KSOCKETDIR" [OTHER_USER]
3. artsd -l 0 -a alsa
OR: kdeinit
OR: lnusertemp socket

Actual results:
A ${KSOCKETDIR}XXXXXX directory is created by mktemp(3), with all the usual implications, then symlinked to ~/.kde/socket-$HOSTNAME.

Expected results:
mkdtemp(3) should be used to create the fallback socket directory instead of mktemp(3).

Additional info:
This was fixed upstream in commit cc5515ed7ce8884c9b18169158ba29ab2f7a3db7 (together with a bunch of unrelated changes) during the Qt3->4 porting phase, so kdelibs-4.x should never have been affected by itself.  However, if the socket directory is created first by aRts or KDE3, as long as it exists it would also be used by KDE4 processes.

The relevant part of said commit should backport easily to both arts (mcop/mcoputils.cc) and kdelibs3 (kinit/lnusertemp.c):

https://quickgit.kde.org/?p=kdelibs.git&a=blobdiff&h=8c0f6401271c495c68e340e06b09239eb755ce5e&hp=45b72f0d5c3421b571e9515497352a0a9942a075&hb=cc5515ed7ce8884c9b18169158ba29ab2f7a3db7&f=kinit%2Flnusertemp.c