Re: Minor 'help' defect.
On 5/2/18 5:06 PM, th...@vmware.com wrote: > > I'd like to report the minor issue that the 'help builtin' command has > an extra '.' at the end of the 'exit status' section. Thanks for the report. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Small fix manual
Missing comma in the following sentence: If the variable exists but does not have a numeric value (or has no value) then the default is 10 It should read: If the variable exists but does not have a numeric value (or has no value)*,* then the default is 10
Re: Small fix manual
On 5/3/18 11:01 AM, Jorge Maldonado Ventura wrote: > Missing comma in the following sentence: > > If the variable exists but does not have a numeric value (or has no > value) then the default is 10 > > It should read: > > If the variable exists but does not have a numeric value (or has no > value)*,* then the default is 10 Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
[PATCH] `bind -x' inside `bind -x' bindings causes execution of random strings
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc'
-DLOCALEDIR='/home/murase/opt/bash-4.4.19/share/locale' -DPACKAGE=\
'bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2
-march=native -Wno-parentheses -Wno-format-security
uname output: Linux padparadscha 4.13.13-100.fc25.i686 #1 SMP Wed Nov
15 18:24:19 UTC 2017 i686 i686 i386 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
After calls of `bind -x' inside functions called via `bind -x',
random strings are executed as a command.
This happens in the following way: When the binding is overwritten
using `bind -x' inside the function called through `bind -x' bindings,
the original string registered for the binding is deallocated although
it is still under evaluation. Then the memory block will be allocated
for other purposes and the content will be rewritten. Finally the new
data written to the memory block is evaluated.
Repeat-By:
The following example is a minimal example that reproduces the problem.
$ bash-4.4 --norc
$ f1() { bind -x '"\C-t": f1'; }; f1
After this, on typing `C-t', a random string is executed as a
command string and produces error messages like:
bash-4.4: $'\317\003': command not found
At least all the versions from Bash 4.0 to Bash 4.4 have the same
problem. I haven't checked for Bash 3.2 or older versions.
Fix:
Maybe the usage in the above example seems useless to some people,
but it's just a reduced example. In my complex scripts I do need to
rebind key bindings in `bind -x' functions. I attach a patch for devel
branch to allow safe `bind -x' inside the function called through
`bind -x' bindings.
Also the execution of random memory contents can generally be a
security issue although I'm not sure if this problem can really be
used for attacks. Basically the content written to the deallocated
strings is not under control, but it's difficult to ensure that there
is no way for other user to control the content. So maybe it's better
to apply this fix also to older versions of Bash.
Best regards,
Koichi
0001-fix-a-bug-that-random-commands-are-executed-after-bi.patch
Description: Binary data
Re: [PATCH] A terminating signal has to complete a bash process
On 5/1/18 7:55 PM, Andrei Vagin wrote: >> If it's not obvious, I'm trying to determine whether making this change >> will add any more value than simply exiting (perhaps with a particular >> exit status). > > It will add more value. Without this changes, we will not know whether a > bach process crashed or exited. If it will not generate a core dump after > a crash, the tools like abrtd, coredumpd, etc will not detect this crash > and will not report about this abnormal behaviour. OK, we'll try it. I'll be interested to see if any core dumps created by causing a SIGSEGV will overwrite any stack information from the `real' fatal signal. Thanks for the patch. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
