#1072669 tor iterates manually over FD hard limit instead of using close_range() in process_unix_exec()

Package:
tor
Source:
tor
Description:
anonymizing overlay network for TCP
Submitter:
Wregyek
Date:
2024-06-06 09:57:04 UTC
Severity:
normal
#1072669#5
Date:
2024-06-06 06:09:12 UTC
From:
To:
Dear Maintainer,

After systemd upgraded from 256~rc3-2 to 256~rc3-7, /proc/sys/fs/nr_open
changes from 1048576 (0x100000) to 1073741816 (0x3ffffff8), causing some
applications (e.g. Tor Browser) to spend a lot of time to iterate through the
max filedescriptors and close() them before exec(), like
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013821.html .
#1072669#10
Date:
2024-06-06 09:07:10 UTC
From:
To:
Control: reassign -1 torbrowser-launcher
Control: retitle -1 tor browser iterates manually over FD hard limit instead of using close_range()
/proc/sys/fs/nr_open
some
through the
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013821.html

Yes, that was intentional as per changelog. Iterating over the hard
limit is a bug and needs to be fixed in the program doing it, which can
be done by simply using close_range():

https://man7.org/linux/man-pages/man2/close_range.2.html

This syscall has been available since Linux 5.9 (bullseye/oldstable).

Reassigning this to torbrowser-launcher.
#1072669#21
Date:
2024-06-06 09:18:44 UTC
From:
To:
Title could be:

tor browser iterates manually over FD hard limit instead of using close_range() when launching pluggable transports.

See process_unix_exec() in src/lib/process/process_unix.c of tor.