On Wed, Apr 19, 2023 at 11:45 PM Adhemerval Zanella Netto <adhemerval.zane...@linaro.org> wrote: > > I might be missing something, but why statically linked only? I don't > > see anything like that in elf/Makefile (but maybe I don't know where > > to look, please tell me!), and also the same behavior is certainly > > exhibited by dynamically linked executables too. That ls -l I posted > > above is from a dynamic executable. > > At least on Hurd, __libc_check_standard_fds is only built for !SHARED.
Right, so I see that there is a separate Hurd version of this. My patch attempted to change the generic csu/check_fds.c, not the Hurd version. (Maybe there's no need to add O_IGNORE_CTTY into the generic version then). In the Hurd version all the logic is in init_standard_fds (which runs through the _hurd_fd_subinit hook) and not in __libc_check_standard_fds (), which is empty and indeed only built for !SHARED -- as the comment there says, to make sure this file is pulled in when linking against libc.a. Also the Hurd version still does check_one_fd (STDIN_FILENO, O_RDONLY); check_one_fd (STDOUT_FILENO, O_RDWR); check_one_fd (STDERR_FILENO, O_RDWR); and opens /dev/null (not /dev/full), so in any case either the generic one needs changes, or the Hurd one. If we want to port the "always fail" change onto the Hurd version, we can take advantage of the fact that on the Hurd we can truly open /dev/null with mode = 0 (not O_RDONLY), and it will be neither readable nor writable. > >> is this really needed now? playing silly games with this fds will always > >> result in silly prices. > > My understanding of this code is to enforce that on setuid program with > stdin/stdout/stderr closed any operation fail. Yes, but is that still considered desirable / a good idea? As opposed to making such operations no-op successfully (opening /dev/null with the expected mode). Sergey
