Bug 28377 - closefrom_fallback fails when /proc/self/fd is not present, which causes unexpected behavior with openssh
Summary: closefrom_fallback fails when /proc/self/fd is not present, which causes unex...
Status: UNCONFIRMED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.34
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-22 22:35 UTC by william.wilson
Modified: 2021-09-27 13:18 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description william.wilson 2021-09-22 22:35:58 UTC
A valid use case of sshd is to run in a "chroot" that actually looks nothing like a root filesystem. If this is attempted in a kernel that does not implement the close_range syscall (5.8 or older) the fallback_closefrom function in glibc 2.34 looks for /proc/self/fd and returns an error if it is not found. This implementation may want to consider scenarios where /proc/self/fd is not present.
Comment 1 william.wilson 2021-09-22 22:37:09 UTC
I have also created https://bugzilla.mindrot.org/show_bug.cgi?id=3349 to track this with openssh.
Comment 2 Adhemerval Zanella 2021-09-27 13:18:55 UTC
As Florian has state in the https://bugzilla.mindrot.org/show_bug.cgi?id=3349, there is not much we can do make it work reliable on Linux. The RLIMIT_NOFILE fallback some implementations (such the one used on openssh at openbsd-compat/bsd-closefrom.c) is not possible because it does not really describe the descriptor range, and iterating over all possible file descriptors values (INT_MAX) is prohibitively performance-wise. It might work on openssh since it controls when and how it uses RLIMIT_NOFILE, but it not an option for glibc.

So I think it is a fair assumption that if you want to support closefrom() on a kernel without the syscall suppport, you need to provide the another feasible kernel interface to allows it (procfs).

Another option is to either abort if /proc can not be opened or remove the fallback (and abort() as well).

In any case, I am inclined to close this bug.