Re: [RFC PATCH v2 4/7] csu: Fix standard fds' mode

[Sergey Bugaev]

On Wed, Apr 19, 2023 at 11:45 PM Adhemerval Zanella Netto
<adhemerval.zanella@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