SUMMARY Programs registered as file handlers are being launched with file descriptors 1 and 2 closed, which is a problem if those programs open any files as they will be assigned the first available file descriptors (1, then 2), then any later code in that program (or in any child process it creates) will end up unwittingly attempting (and possibly succeeding) to write to some random files when they intended to write to stdout or stderr. This all happens whether using Dolphin or the command-line tool kde-open (so I'm not sure this is the proper categorization of this bug report, please rebucket as you see fit). STEPS TO REPRODUCE 1. Create a shell script which does this: ls -l /proc/$$/fd/ >/some/log/file.txt 2. Register script as default handler for some file type in KDE settings. 3. Open file of that type from Dolphin, or from the command-line run kde-open on that file. OBSERVED RESULT The output written to that file will show that only file descriptors 0 and 255 are open, in other words 1 and 2 had been closed. EXPECTED RESULT I'd expect 1 and 2 to be open and pointing to some pipe or to /dev/null. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 ADDITIONAL INFORMATION In my case, the handler program was a shell script which ran `exec wine start.exe /unix "$1"` (i.e. open file using whatever program is registered to handle it within Wine environment). Wine was getting stuck on something and then never launching the program. Changing my script to do `exec wine start.exe /unix "$1" &>/dev/null` (i.e. open /dev/null at file descriptors 1 and 2) fixed it for me. The answer for https://serverfault.com/questions/704298/dangers-of-closing-file-descriptors explains why closing standard file descriptors can be a bad idea. This page here also explains why it's a bad idea: https://www.oreilly.com/library/view/secure-programming-cookbook/0596003943/ch01s05.html
Some more references that leaving standard file descriptors closed is a bad idea (particularly for stderr): https://www.austingroupbugs.net/view.php?id=555 https://stackoverflow.com/questions/4972994/how-to-close-stdout-and-stderr-in-c https://unix.stackexchange.com/questions/163955/is-more-efficient-than-dev-null https://www.cygwin.com/bugzilla/show_bug.cgi?id=13983
I have a VM which runs xfce and I tried a similar experiment there to see how its file manager (Thunar) does this. It redirects file descriptors 0 and 1 to /dev/null, and 2 to ~/.xsession-errors. When running xdg-open, it redirects file descriptor 0 to /dev/null, and 1 and 2 both to the current pseudo tty in which xdg-open was run (in my case it was /dev/pts/1).
Okay this is very strange. This problem does normally occur for me pretty regularly, but I tried it again just now (have *not* rebooted or restarted KDE or Plasma) and both Dolphin and kde-open are no longer closing (or leaving closed) the standard file descriptors. There must be some condition under which it is doing this.
Well wouldn't you know it, the cause was some other script which was launching Dolphin with the standard file descriptors closed. Cases where this was working must've been when Dolphin was launched without this script. I'll keep this open for a bit while I confirm but I'm pretty sure that was the reason. Though I don't know how that ended up affecting xdg-open.
I still don't know how this affected xdg-open, but I'm pretty confident the issue is fixed. Will reopen (or create a more precise new bug report) if not fixed.