Insecure use of /tmp in libappindicator-based SDL_Tray implementation

[smcv]

src/tray/unix/SDL_tray.c uses a predictable path in /tmp, which makes it vulnerable to a classic time-of-check/time-of-use vulnerability involving symbolic links. On a multi-user system, an attacker who can predict (or learn) the process ID of a SDL game that uses the tray could predict the filename and create a symbolic link /tmp/sdl_appindicator_icon_${pid}_${sequence}.bmp.

When SDL writes out a new icon with that name, it will traverse the symbolic link and overwrite a filename of the attacker's choice using the privileges of the victim. There is an impact on availability (denial of service) by making the victim overwrite a file that they wanted to keep, and possibly also an impact on confidentiality or integrity (for instance if the attacker overwrites a file that is meant to be kept secret as part of an authentication mechanism).

For example:

victim$ ls ~/will-be-overwritten
(doesn't exist, or has "old" contents)
victim$ ${builddir}/test/testtray

attacker$ cd /tmp
attacker$ ls sdl_*
sdl_appindicator_icon_169458_0.bmp
sdl_appindicator_icon_169458_1.bmp
attacker$ ln -s /home/victim/will-be-overwritten sdl_appindicator_icon_169458_2.bmp

(victim uses the "Change Icon" menu option)

victim$ ls ~/will-be-overwritten
(exists, has been overwritten with a copy of the icon)

Recent Linux kernels optionally mitigate this with the fs.protected_symlinks sysctl, which many distros enable by default. Other Unix OSs (*BSD, etc.) might have similar OS-specific mitigations.

The 3.1.8 preview release and git snapshots > 3.1.6 (specifically since 01b9b0e, I think) are vulnerable. SDL 2.x and the 3.1.6 preview release are unaffected.

I think the simplest solution to this vulnerability is to create a temporary directory owned by the user who is running the SDL program, with restrictive permissions (0700), and put the .bmp files in there: other users will be unable to modify that directory, so we are protected. This does not protect against an attacker who is able to run arbitrary non-sandboxed code under the victim's uid, but under the typical Unix security model nothing can be protected against such an attacker anyway.

libappindicator already depends on GLib and GTK, so we can use GLib's g_mkdtemp() or g_dir_make_tmp() rather than needing to wait for #10966 or similar.