Re: [PATCH3] Re: avoid closed stdin() in zle widgets

[Stephane Chazelas <stephane.chazelas@gmail.com>]

2017-06-14 15:44:25 -0700, Bart Schaefer:
> On Jun 12,  8:02pm, Stephane Chazelas wrote:
> }
> } My point is that a command should be able to reasonably make some
> } assumptions, like:
> } 
> } - stdin should be open for at least reading
> } - stdout, stderr should be open for at least writing
> 
> Although I understand the security implication of accidentally opening
> some other file onto fd 0/1/2, I can't agree with the above statements.
> Taken to the logical conclusion, the >&- <&- or 2>&- operators would
> be required always to fail with an error.
> 
> It should not be the shell's job to plug this hole.  I will agree that
> a valid argument is that the shell should not implicitly *open* this
> hole, which one could also argue is what the completion system had
> been doing in spite of the behavior being documented.  However, with
> these two likely exceptions --
> 
> } - argv[0] should be set (argc > 0)
> } - no dups in the environment
> 
> -- there is nothing else on your list where I would agree that the
> shell should ignore the user's directives in the name of protecting
> an external command from itself.

I think you misinterpreted what I said, I did not imply that the
shell should take upon itself to prevent users from creating
those pathological conditions, but that it should not take upon
itself to creating those pathological conditions itself.

That's the "Be conservative in what you do" in the "Be
conservative in what you do, be liberal in what you accept from
others" (and yes, it's a case where "dircolors" did not fully
apply the "be liberal in what you accept").

In other words, I would certainly not want zsh to refuse to <&-
just like I would not want close(0) in C to fail.

I would even welcome new options to the "env" utility to execute
a command without arguments or with arbitrary argv[0], or with
duplicate env vars or with env strings without = characters so
one can test applications in those pathological conditions (and
possibly raise awareness on the security implications), but
if we put aside those testing cases, an application like zsh
should not intentionaly (by itself) cause those pathological
conditions.

The case of zle widgets running commands with stdin close was
not a case where the user requested stdin to be closed.

> } $ (limit stacksize 100k; zsh)
> } zsh: segmentation fault
> } zsh: segmentation fault
> } 
> } (twice!?). Is that a bug?
> 
> I believe what's happening is that both the zsh inside the subshell
> and the parent handling the subshell exit are reporting the error,
> so one failure / two messages.
> 
> However, I can't test directly because I can start zsh -f with a hard
> limit stack size of *zero*, so I'm quite curious as to why you get a
> crash on 100k.

I suspect your system won't bring the stack size below some
threshold (or just ignores that  limit). With a null stack size,
you woudn't even be able to call execve()

My several segvs were probably down to some child processes
spawned by my ~/.zshrc dying there upon stack overflow.

The point was just an illustration that you can't always deal
with all pathological conditions, you have to put a limit on
the amount of effort you're willing to put into covering for all
possible pathological cases, and IMO a closed stdin is one such
pathological case (even if not as much as a very small stack
size, or random memory bit flips), and one you can blame on the
calling application.

-- 
Stephane