[Bug 3547] shell read is maybe too safe
ska-dietlibc at skarnet.org
Mon May 9 12:45:10 UTC 2011
> I don't think that such SIGSTOP behavior isn't a kernel bug.
Well, it's certainly easier to assume that it is, but Single Unix really
says nothing about it.
> It would break a lot of programs, because no one stress tests
> their apps with massive SIGSTOP/SIGCONT storms, so many apps
> are bound to contain bugs wrt this.
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.
> 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. Better consider existing apps
hopelessly broken and focus on doing the right thing from now on.
> SIGCONT is just another signal - you can even have a handler for it.
> Try it if you don't believe me - it works:
Oh, yes it is, and I believe you :) The fact remains that other signals
can randomly happen. Who ever thinks about trapping SIGTSTP, SIGTTIN and
> This is *shell*. In shell, people may use fd's *directly*:
> echo yo! >&23
> What will happen if they'd write stuff to the write end
> of the signal pipe?!
> It is already a huge PITA to prevent users from seeing/reading from
> the fd's opened to the currently running script! Think about this:
> Therefore, signal pipe isn't an attractive solution.
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() ?
That doesn't sound right.
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
> 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().
I'm afraid that if you're not allowed to use internal fds for notification
purposes, you're basically screwed. Or maybe you could try to architecture
your shell loop around a notification mechanism that does not involve fds,
such as System V message queues. I don't even want to imagine how ugly that
would be. XD
More information about the busybox