What is file descriptor 47 used for?

Question

I have noticed that when I run

ls /proc/self/fd

I get the following output:

0  1  2  3  47

Obviously, 0, 1 and 2 are the descriptors for stdin, stdout and stderr, respectively, and 3 is the descriptor which ls uses to access the directory.

But what is 47? It must be something passed by the shell (and not something specific to ls) because running cat outputs:

$ cat /proc/self/fd/47
cat: /proc/self/fd/47: Permission denied

# example of running cat on a non-existent file descriptor
$ cat /proc/self/fd/46
cat: /proc/self/fd/46: No such file or directory

ls -l says that it is connected to anon_inode:inotify.

I am using Arch Linux with KDE, and this seems to matter, because it doesn't seem to happen if I run commands from tty. It's not shell specific (it happens on both bash and zsh), though it may be terminal specific (I am using Konsole). Regardless, isn't the shell supposed to close every descriptor except 0-2 before exec (or have them flagged with O_CLOEXEC)?

I am running KDE Plasma 5.27.10.

EDIT: Since sudo closes all descriptors except 0-2, I tested sudo konsole, and the instance of zsh inside this new terminal doesn't leak descriptor 47 into new processes. This means that there's nothing wrong with Konsole itself, but that it receives the descriptor from its parent (which appears to be plasmashell).

Answer 1

There's nothing particularly special about FD 47. At least, nothing standard.

When a file descriptor is opened, a flag can be set indicating if it should be closed or not on an exec() call to another program. Most programs ignore any open file descriptors above the first 3 (and sometimes 4), so if something left one open and marked it to stay open across exec, it could stay open through multiple programs. Very likely, it was left open by mistake; this is a file descriptor leak bug. It might be tricky to trace it back to what left it open, especially considering what left it open may not be running anymore.

You might not see it open from a shell in a terminal because some shells meticulously close all extraneous open file descriptors in the interests of cleaning up as part of their initialization. Leaking file descriptors unintentionally could be a security vulnerability, as the leaked FD could carry data that could be leaked unintentionally to another program.

This would be especially dangerous when changing users, so it makes sense for sudo to close anything extra.