Re: pipefail with SIGPIPE/EPIPE
> Errexit (a.k.a. set -e) is horrible, > and you should not be using it in any new shell scripts you write. > It exists solely for support of legacy scripts. Wow. For those of us who don't know this, what should we be using instead? Is using a trap on ERR any better? Is your suggestion that || exit 1 be added to the end of every command? (Potentially of mild interest is this thread on Hacker News from earlier today, where multiple people are suggesting the usage of "set -e" along with "set -u" and "set -o pipefile".) https://news.ycombinator.com/item?id=13940322
Re: REGRESSION: shellshock patch rejects valid function names
[I am terribly sorry that my In-Reply-To is wrong :/]
- Eric Blake ebl...@redhat.com wrote:
... Remember, the security hole of
Shell Shock is NOT what the function is named, but the fact that
arbitrary variable contents were being parsed. ...
Not quite: the point of exploit can be in the variable name.
$ env 'date;x=() { :;}' bash --norc -c :
Sat Sep 27 20:40:41 UTC 2014
Segmentation fault (core dumped)
$ bash --version | head -n 1
GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu)
While AFAIK you can't create functions with names that eventually lead to
dangerous variable names, this is due to a quoting requirement (to place that
;, for example, in a function definition statement, I'd have to quote it, and
check_identifier refuses to allow any quoted characters) that happens when
parsing the function as it is created in the first place that are not quite
so easily replicated when trying to use check_identifier to validate the name
before importing the function (hence why, even with the patch I provided
yesterday that verifies function names before importing using a mechanism
similar to that used for definitions, I still rely on SEVAL_FUNCDEF to catch
date;x: the ; has not been quoted, so check_identifier considers it not to
be a problem; incidentally, this is why my original patch concept, before I
understood the new SEVAL_FUNCDEF and verified it was sufficient as in the patch
I provided yesterday, involved running the name itself through the parser to
verify it was a single word).
Re: REGRESSION: shellshock patch rejects valid function names
- Ángel González an...@16bits.net wrote:
The patch seems straightforward:
diff --git a/variables.c b/variables.c
index 92a5a10..6552e69 100644
--- a/variables.c
+++ b/variables.c
@@ -361,7 +361,7 @@ initialize_shell_variables (env, privmode)
...
- if (legal_identifier (name))
+ if (check_identifier (name))
...
This patch would not work (it would not even compile if you tried it, in fact
;P) because check_identifier takes two arguments: the second argument is
whether to internally run legal_identifier on the name. Additionally,
check_argument takes a WORD_DESC, not a string.
If these two issues were fixed (by using make_word or something, and then
passing 0 or preferably posixly_correct), I am concerned that this might
undermine the security fix itself, as check_identifier could potentially allow
ludicrous things to be pasted in the name?
It seems, however, like SEVAL_FUNCDEF is sufficient to keep most things that
should not happen from actually happening? I tested the attached patch against
the following test case. It might be that I went overboard and don't actually
need quote_escapes (I'm new to bash).
(function std:echo() { echo $@; }; export -f std:echo; env 'x$(date)=() {
:;}' 'x`date`=() { :;}' 'date;x=() { date;}' ./bash --norc -c 'std:echo hello
world')
./bash: `x$(date)': not a valid identifier
./bash: error importing function definition for `x$(date)'
./bash: `x`date`': not a valid identifier
./bash: error importing function definition for `x`date`'
./bash: warning: date;x: ignoring function definition attempt
./bash: error importing function definition for `date;x'
hello world
colon-functions-attempt-1.diff
Description: Binary data
Re: backward-kill-word is not refreshing correctly
And help I will definitely attempt. Here are the requested values: col_lendiff = 5 _rl_last_c_pos = 194 _rl_screenwidth = 126 Some random other variables, in case they end up being requested: lendiff = 5 old = 8403456 new = 8457216 ne = 8457410 oe = 8403655 temp = 0 My cursor is definitely not past the end of my screen. This seems to be a bug in the way prompts are handled. I have a ludicrously complex prompt that has a large number of non-printing characters. This issue then only occurs (as one would expect) if the math works out so the total number of characters in the prompt (/including non-printing ones/) plus my true cursor offset from the prompt is past the edge of the screen, but isn't /actually/. And yes, I am definitely being very careful about using \[ and \] to bound my non-printable characters. I even got it down to this very trivial test case, where ... indicates more numbers to fill space here, so I could easily see yes, the \[ and \] are placed correctly. ;P PS1=$'0123456789...0123456789\\[\e[0m\\]' However, even given this knowledge, the bug remains unreproducable on my amd64 box. I have, however, found someone using FreeBSD who said he was seeing related-sounding issues with Bash 4.x, and I know he's also using colored prompts. I am also now confident this is the same problem Matt was having, as once he had killed enough words to get out of the danger region (his prompt was probably not as ludicrous as mine), it started working again. Also, while looking into this (in the hope of reproducing it on Linux), I noticed that in builtins/Makefile.in, LDFLAGS_FOR_BUILD uses LDFLAGS which uses CFLAGS... which is the CFLAGS for the target, not for the build. This became a problem as I tried to do a 32-bit build of bash (using CFLAGS='-O2 -m32 -g') and mkbuiltins.o was compiled without -m32 (as it uses CCFLAGS_FOR_BUILD, which bypasses CFLAGS to use BASE_CCFLAGS) but was being linked with -m32. I do not yet have a correct fix for this unrelated issue. Sincerely, Jay Freeman (saurik) sau...@saurik.com http://www.saurik.com/ - Original Message - From: Chet Ramey chet.ra...@case.edu To: Jay Freeman (saurik) sau...@saurik.com Cc: bug-bash@gnu.org; m...@ice.filescope.com; chet.ra...@case.edu Sent: Saturday, April 11, 2009 9:14 AM Subject: Re: backward-kill-word is not refreshing correctly ... I can't reproduce the problem, and it seems to only appear in builds for your iphone. I'm going to need help with it. :-) Please check the values of _rl_last_c_pos and _rl_screenwidth when this code is executed and the problem occurs. It's likely that the former is set incorrectly somewhere, but I can't tell that for sure yet. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.edu http://cnswww.cns.cwru.edu/~chet/
Re: backward-kill-word is not refreshing correctly
On Mar 18, 6:55 pm, m...@ice.filescope.com, zy...@ice.filescope.com wrote: ... When I type a long string of text and start pressing ctrl-W to backwards-kill words, bash deletes the words but doesn't visually refresh (the words still appear on the command line). This was not occurring for me in the 3.x series of Bash. Repeat-By: Write this text on the command line: sample text sample text sample text sample text sample text. Start pressing ctrl-W and notice it takes a few kill-words before the words start disappearing. --Matt Zyzik I having a problem similar to this. For me, kill-word /never/ refreshes the screen. Additionally, moving up/down through the command history doesn't always cause a refresh either (in a manner deterministic but stochastic). I am using 4.0.17 on arm-apple-darwin9. I also cannot reproduce this problem with bash 3.2. Unfortunately, I cannot reproduce this problem on x86_64-unknown-linux-gnu. I have tried building bash 4.x against ncurses 5.4 and 5.7, I have tried compiling it against a standalone readline 6.x and using a built- in copy, and I have tried compiling both for thumb and arm. I also have tried copying the terminfo database off of my working x86_64 box and I have even tried running without any terminfo database, in the hope of determining why I can't reproduce the problem on my server. Does anyone have any hints on what I could do to debug this? What sections of code this might be using? I know very little about how bash/readline/ncurses work together to handle this problem: even just saying check out these couple functions could be useful, so I could start seeing if they are getting called correctly.
Re: backward-kill-word is not refreshing correctly
When I type a long string of text and start pressing ctrl-W to backwards-kill words, bash deletes the words but doesn't visually refresh (the words still appear on the command line). This was not occurring for me in the 3.x series of Bash. I having a problem similar to this. For me, kill-word /never/ refreshes the screen. Additionally, moving up/down through the command history doesn't always cause a refresh either (in a manner deterministic but stochastic). ... I have tried building bash 4.x against ncurses 5.4 and 5.7, I have tried compiling it against a standalone readline 6.x and using a built- in copy, and I have tried compiling both for thumb and arm. And, it turns out that had I tested a standalone readline 5.2, it would have worked fine ;P. The problem was introduced somewhere in readline between bash 3.2 and 4.0. I figured this out by playing with bash some to figure out where it was displaying things to the screen, and then started whittling away at the diff of readline's display.c from 3.2 to 4.0. In the end I managed to isolate it down to the single diff hunk that was causing the problem. It should be made clear that I have no clue what this code is doing, or why it was changed from 3.2 to 4.0: all I know is that the old version worked for me, and this one did not. I am therefore not advocating that removing it is the correct fix, and am only providing this information in the hope it will help debug the issue. So, this patch solves my problem, and maybe it will solve Matt's as well: http://svn.telesphoreo.org/trunk/data/readline/lendiff.diff While I'm at it, I highly recommend removing the extraneous CFLAGS overrides from readline's configure.in: they break autoconf's gcc -g detection, if nothing else. http://svn.telesphoreo.org/trunk/data/readline/cflags.diff Sincerely, Jay Freeman (saurik) sau...@saurik.com http://www.saurik.com/
