[dolphin] [Bug 465103] New: Dolphin and kde-open should not be closing file descriptors 1 and 2

Michael bugzilla_noreply at kde.org
Wed Feb 1 05:53:39 GMT 2023


https://bugs.kde.org/show_bug.cgi?id=465103

            Bug ID: 465103
           Summary: Dolphin and kde-open should not be closing file
                    descriptors 1 and 2
    Classification: Applications
           Product: dolphin
           Version: 22.08.3
          Platform: Gentoo Packages
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: dolphin-bugs-null at kde.org
          Reporter: burnsmellfactory at gmail.com
                CC: kfm-devel at kde.org
  Target Milestone: ---

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the kfm-devel mailing list