This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make sure GDB uses a valid shell when starting the inferior and to perform the "shell" command
- From: Matt Rice <ratmice at gmail dot com>
- To: Paul_Koning at dell dot com
- Cc: simon dot marchi at ericsson dot com, Eli Zaretskii <eliz at gnu dot org>, Sergio Durigan Junior <sergiodj at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 24 Jul 2015 14:36:38 -0700
- Subject: Re: [PATCH] Make sure GDB uses a valid shell when starting the inferior and to perform the "shell" command
- Authentication-results: sourceware.org; auth=none
- References: <1437761993-18758-1-git-send-email-sergiodj at redhat dot com> <55B2850D dot 6030306 at ericsson dot com> <87k2tp5q3g dot fsf at redhat dot com> <838ua52wmp dot fsf at gnu dot org> <87fv4d5p8l dot fsf at redhat dot com> <837fpp2uz5 dot fsf at gnu dot org> <94F6A309-A197-4A71-BEB9-42E009DD1EB5 at dell dot com> <55B2A24B dot 8000209 at ericsson dot com> <6E0AD60C-689F-4958-964D-FD560FE77C06 at dell dot 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..