Bug 465103

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