[Bug 3547] shell read is maybe too safe

[Denys Vlasenko]

On Mon, May 9, 2011 at 2:45 PM, Laurent Bercot <ska-dietlibc at skarnet.org> wrote:
>  Oh, yes.
>  The huge majority of Unix apps *do* contain bugs wrt signals, starting
> with every app that uses a libc that does not protect system calls from
> EINTR. It's not hard to crash an entire system with signal abuse.

libc must not protect system calls from EINTR. It's app's job.

>> Practicality dictates that the kernel-side fix is a better place for this
>> than auditing quadrazillion of syscalls in userspace code.
>
>  That won't fix the other zillion of programs that just forget to set the
> SA_RESTART flag on the signals they trap.

Those apps usually call signal() to set a handler. In Linux,
signal() sets SA_RESTART.

> The fact remains that other signals can randomly happen.
> Who ever thinks about trapping SIGTSTP, SIGTTIN and
> SIGTTOU ?

If kernel will make sure stop signals never cause EINTR,
then it's not a problem either.


>  Does that mean that when you write a shell, you completely forbid
> yourself to use internal file descriptors ? You are not allowed to use
> open files for internal shell use ? That means, no way to listen to
> asynchronous notifications with a poll() ?

Yes, you can't willy-nilly open shell-internal fds. You need to carefully
manage them.

> If I were to write a shell, I'd document a set of fds that are reserved
> for internal use (something high like 240-255, in order to keep low-
> numbered fds free for users), and make the shell crash with a loud error
> message if a user script is attempting to mess with fds in that reserved
> range. It's a slight breach of the specification, but it makes things
> manageable.

That's roughly what we do already.

>> Will it work if I'll set signal handlers to SA_RESTART, but perform
>> all reads by checking data availability via poll() beforehand?
>
>  No. A signal could still arrive between your poll() and your read().

Not a problem: read wouldn't block and wouldn't EINTR. Thus,
the situation would be equivalent to signal arriving a millisecond later.

-- 
vda