Re: glob qualifier '-' doesn't work correctly on dangling symlinks

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Stephane Chazelas wrote on Tue, 14 Apr 2020 13:38 +0100:
> 2020-04-14 12:02:41 +0000, Daniel Shahaf:
> [...]
> > Counter-argument: since an ENOMEM during symlink resolution causes
> > «(-@)» to presume the symlink is broken, the zsh language is
> > non-deterministic: what «intact-symlink(N-@)» will expand to will
> > depend on whether there is enough memory at runtime.
> > 
> > Shouldn't an ENOMEM during expansion of «intact-symlink(N-@)» result in
> > an error?  "In the face of ambiguity, refuse the temptation to guess."
> > 
> > That is: I think there's a qualitative difference between ENOENT and ENOMEM.  
> [...]
> 
> ENOMEM/EFAULT/EINVAL are the kind of pathological errors for
> which I'd say you can't do much more than best effort.
> 
> If you run out of kernel memory to the point that stat() in your
> shell fails, or if bits start to randomly flip causing
> EFAULT/EINVAL, more things are going to fail and an inaccurate
> glob expansion is probably the least of your concerns.
> 

I'm sure you can imagine other transient failure modes, e.g., a network
error with a network-based filesystem.

> And what can you do? Check errno after each and every system
> call?

I am talking about a specific stat(2) syscall in glob.c.

> And what's the list of errno values we should consider?
> And how should we handle them?

If there is agreement that not all errno values should be treated the
same way, then we can move on to answering these questions.

> How likely is it to happen?

Filesystems do get corrupt or go offline from time to time.

> What's the worst that can happen if it's not handled "properly"?

Depends on how we handle it, obviously.  If we handle it by returning an
error and aborting the current command line, the worst that can happen
is that a command line (or script) would be aborted, whereas currently
it would silently continue execution with wrong data.

> Can that be exploited?

That's a question for the script author.

> Say you're the sysadmin that needs to fix that low kernel memory
> situation, it's probably better to keep your shell running as
> long as possible.

No one proposed to kill the shell.  An error in an interactive shell
just aborts the current command-line and drops the user back to the
prompt.

> That's a narrow ridge to walk on there. I agree that letting the user
> know of that pathological condition is useful, but we need to be
> careful the cure be not worse than the disease.
> 
> In any case, I would imagine this kind of consideration has
> already been discussed at length here and elsewhere. In anycase,
> I'm no expert at all on that.