[Bug 3547] shell read is maybe too safe

Harald Becker ralda at gmx.de
Mon May 9 13:28:15 UTC 2011


 Hallo Laurent!

>> This is  *shell*. In shell, people may use fd's *directly*:
>> (...)
>> 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
> manageable.

I highly agree to this. It at least was the way it has been handled in
bash (at the time I dig deep into bash code, >10 years ago). Don't know
if this type of fd protection is still in there. Older shells even
limited user fds to the single (or two) digit range (that is 0..9 or
0..99). Any user access to fds not bound to that range got rejected.
Internal fds got moved to higher fd numbers (10+ or 100+, older bash
used 128+). So that is definitly not only an idea, it is well known
shell practice to protect pipe and other internal shell fds from
unwanted user access.

After check: Newer versions of bash doesn't seem to have a fd limit.
Allows values up to 1023 ... don't know if there is another type of
internal fd protection instead. Did anybody ever use such high fd
numbers on shell command lines or in scripts?

--
Harald



More information about the busybox mailing list