[Bug 3547] shell read is maybe too safe
vda.linux at googlemail.com
Mon May 9 13:29:58 UTC 2011
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
> 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
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.
More information about the busybox