Re: [PATCH] Make sure GDB uses a valid shell when starting the inferior and to perform the "shell" command

[Matt Rice <ratmice@gmail.com>]

On Fri, Jul 24, 2015 at 1:42 PM,  <Paul_Koning@dell.com> wrote:
>
>> On Jul 24, 2015, at 4:38 PM, Simon Marchi <simon.marchi@ericsson.com> wrote:
>>
>> On 15-07-24 04:25 PM, Paul_Koning@Dell.com wrote:
>>> But if you omit a shell, is the user of that shell blocked from using gdb?  That’s not a good failure mode.  It seems to me that omitting a non-shell is much more forgiving: all that happens is that you don’t get the friendly error message.
>>>
>>> So that says the explicit list should be of non-shells.
>>>
>>>      paul
>>
>> With Eli's suggestion, if SHELL is valid but gdb doesn't know about it (e.g.
>> SHELL=/my/super/duper/shell), it will fall back to using /bin/sh.  So no,
>> the user wouldn't be blocked.
>>
>>
> Not unless the features in that unknown shell are needed for the application to function correctly.

another case of this is shells which actively restrict the application to some
 subset of available functionality

http://plash.beasts.org/index.html#section1

i'm not sure about the following being unfamiliar with it, but it
seems a likely candidate for this as well.

https://github.com/trombonehero/capsh

an unrecognised shell in this case could lead to increased authority
of the inferior process, as the general effort here is to restrict
processes to those file descriptors that the shell passes to it and
remove the ability to obtain new file descriptors the shell has not
blessed..