Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
On 09 Feb 2021 16:40, Chet Ramey wrote: > On 2/9/21 11:51 AM, Mike Frysinger wrote: > > On 09 Feb 2021 11:12, Chet Ramey wrote: > >> On 2/8/21 11:54 PM, Mike Frysinger wrote: > >>> this set of changes between bash-4.3 & bash-4.4: > >>> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e > >> > >> I'm glad you're upgrading to bash-4.4. This change was made nearly five > >> years ago; the time to relitigate it has long passed. > > > > we're on bash-4.3 atm. we would upgrade to the latest if that were actually > > a reliable process. unfortunately, moving between bash versions is often > > full > > of random regressions or changes in behavior. like this one. > > Interesting. I suppose one person's bug fix is another's "random change." I > don't see it in this case, though, since it's a bug fix and making bash do > what its documentation said it did. i'm not complaining that the change was made; in fact, my original report never asked for it to change, or declared it a bug, but was clearly asking for confirmation that it was an intended behavioral change. seems like it should have been included under the compat43 knob since it was changing long standing behavior (bug or otherwise), but it's prob too late for that now too. > > i understand your point, but the real world of shipping code doesn't have > > the > > luxury of burning the house down for the latest shiny features. > > I understand that distribution stability means that you'd like to encase > the shell in amber. i made no such claim or request. my point is upgrading bash versions is guaranteed to break something, intentional or not. i've maintained bash in distros & products since bash-2.05b, so i understand this is simply the reality of the project. jumping more than one release (i.e. to bash-5.1) introduces much more risk than reward which is why we're only moving to bash-4.4 now, and once that settles, we can look at the next major step. > >>> has this buried nugget: > >>> + - shopt_set_debug_mode: make sure error_trace_mode reflects the setting > >>> + of extdebug. This one is tentative. Fix from Grisha Levit > + > >>> > >>> + - shopt_set_debug_mode: call set_shellopts after setting > >>> error_trace_mode > >>> + or function_trace_mode. Fix from Grisha Levit > > You could also have looked in the CHANGES file: > > . Fixed a bug that caused the shell to not enable and disable function >tracing with changes to the `extdebug' shell option. bisecting git is a lot faster than digging through changelog files that are inconsistent across projects and trying to figure out what might or might not be relevant. i wish bash's vcs history had more discrete sets of changes rather than daily code dumps. but it's still an improvement over not having access to any vcs. > > it looks like we can mitigate this with `set -E` after we turn on extdebug. > > it's unfortunate that there's no way to get extended debug info without also > > opting in to side-effects like this. all we really want is to get backtrace > > info for logging messages when we abort down a few layers. > > If it works for you, great. But extdebug is always going to be for the > benefit of the shell debugger. i didn't ask you to change extdebug behavior. i'm asking for subsets of the current extdebug functionality to be exposed without all the other side-effects. e.g. having bash populate the BASH_ARGC & BASH_ARGV env vars for self-introspection. -mike
Re: extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
On 09 Feb 2021 11:12, Chet Ramey wrote: > On 2/8/21 11:54 PM, Mike Frysinger wrote: > > this set of changes between bash-4.3 & bash-4.4: > > https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e > > I'm glad you're upgrading to bash-4.4. This change was made nearly five > years ago; the time to relitigate it has long passed. we're on bash-4.3 atm. we would upgrade to the latest if that were actually a reliable process. unfortunately, moving between bash versions is often full of random regressions or changes in behavior. like this one. i understand your point, but the real world of shipping code doesn't have the luxury of burning the house down for the latest shiny features. > > has this buried nugget: > > + - shopt_set_debug_mode: make sure error_trace_mode reflects the setting > > + of extdebug. This one is tentative. Fix from Grisha Levit > + > > > > + - shopt_set_debug_mode: call set_shellopts after setting > > error_trace_mode > > + or function_trace_mode. Fix from Grisha Levit > > You can take that and find the original bug report, with Grisha's patch: > > https://lists.gnu.org/archive/html/bug-bash/2016-05/msg0.html > > Since the bash-4.3 man page said that setting `extdebug' means that error > tracing is enabled, and implies the opposite is true, it makes sense to > ensure that the `errtrace' value reflects the value of `extdebug' when it's > changed. thanks, i wanted to double check it was intentional. it looks like we can mitigate this with `set -E` after we turn on extdebug. it's unfortunate that there's no way to get extended debug info without also opting in to side-effects like this. all we really want is to get backtrace info for logging messages when we abort down a few layers. -mike
extdebug now implies errtrace which implies `trap ... ERR` execution w/out `set -e`
this set of changes between bash-4.3 & bash-4.4:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=814e1ff513ceca5d535b92f6c8dd9af7554fe83e
has this buried nugget:
+ - shopt_set_debug_mode: make sure error_trace_mode reflects the setting
+ of extdebug. This one is tentative. Fix from Grisha Levit
+
+ - shopt_set_debug_mode: call set_shellopts after setting
error_trace_mode
+ or function_trace_mode. Fix from Grisha Levit
which i'm guessing means this behavior is intentional:
$ bash-4.3 -c 'shopt -p -o | grep err; shopt -s extdebug; shopt -p -o | grep
err'
set +o errexit
set +o errtrace
set +o errexit
set +o errtrace
$ bash-4.4 -c 'shopt -p -o | grep err; shopt -s extdebug; shopt -p -o | grep
err'
set +o errexit
set +o errtrace
set +o errexit
set -o errtrace
we're in the process of upgrading from bash-4.3 to bash-4.4 and it broke
our build scripts because we use `trap ... ERR` with `shopt -s extdebug`,
but we also toggle `set +e` in a few places to avoid trapping. that is
no longer sufficient, and now we have to do `set +eE` and `set -eE`.
example shell script showing change in behavior:
$ cat test.sh
#!/bin/bash
foo() {
false
return 0
}
shopt -s extdebug
trap 'echo invalid trap; exit 1' ERR
foo
echo "pass"
$ bash-4.3 ./test.sh
pass
$ bash-4.4 ./test.sh
invalid trap
the manual text for extdebug didn't change between the versions, so it's
not clear if this is overall intended as a bug fix.
-mike
Re: add generated files to .gitignore
On 05 Mar 2018 14:33, Chet Ramey wrote: > On 3/5/18 1:15 PM, Mike Frysinger wrote: > > On 02 Mar 2018 14:25, Chet Ramey wrote: > >> On 2/27/18 11:46 AM, don fong wrote: > >>> Chet, thanks for the suggestion. > >>> > >>> i still wonder what's the objection to changing .gitignore? > >> > >> I don't think it will be useful to me, since I curate the commits I > >> make to the various branches, but I don't have any real objection if > >> it will help others. > > > > i wish the bash/readline git repos had .gitignore in them so every > > dev didn't have to create it by hand themselves > > OK, since the bash devel branch has one, I assume you mean the master > branches for bash/readline? all the active branches that people would normally use :) so yeah, master & devel would be great, and as new branches are cut off of master/devel, they'll get them for free. i don't think there's any need to backport to older stuff. -mike signature.asc Description: Digital signature
Re: add generated files to .gitignore
On 02 Mar 2018 14:25, Chet Ramey wrote: > On 2/27/18 11:46 AM, don fong wrote: > > Chet, thanks for the suggestion. > > > > i still wonder what's the objection to changing .gitignore? > > I don't think it will be useful to me, since I curate the commits I > make to the various branches, but I don't have any real objection if > it will help others. i wish the bash/readline git repos had .gitignore in them so every dev didn't have to create it by hand themselves -mike signature.asc Description: Digital signature
Re: Another little patch I would like to put upstream
On 07 Dec 2016 19:09, Chet Ramey wrote: > On 12/5/16 11:01 PM, Mike Frysinger wrote: > > using ^ as an anchor doesn't seem that much better than % > > Ultimately, autoconf is the right way to do this. sure, you could add bashbug to AC_OUTPUT and adapt all the vars to be AC_SUBST. i assume you'll just do that in the devel branch ? -mike signature.asc Description: Digital signature
Re: Another little patch I would like to put upstream
On 04 Dec 2016 22:53, Vladimir Marek wrote: > Studio compiler may use things like '-xregs=no%frameptr' for example. > > Thank you > -- > Vlad > # Our compiler flags contain percent sign which get mixed up with percent sign > # seprators used by sed. > > # Submitted to bug-bash@gnu.org > > --- Makefile.in 2014-01-25 13:27:30.0 -0800 > +++ Makefile.in 2015-04-02 11:18:58.143893640 -0700 > @@ -584,10 +585,10 @@ > @echo > > bashbug: $(SUPPORT_SRC)bashbug.sh config.h Makefile $(VERSPROG) > - @sed -e "s%!MACHINE!%$(Machine)%" -e "s%!OS!%$(OS)%" \ > - -e "s%!CFLAGS!%$(CCFLAGS)%" -e "s%!CC!%$(CC)%" \ > - -e "s%!RELEASE!%$(Version)%" -e "s%!PATCHLEVEL!%$(PatchLevel)%" \ > - -e "s%!MACHTYPE!%$(MACHTYPE)%" -e "s%!RELSTATUS!%$(RELSTATUS)%" \ > + @sed -e "s^!MACHINE!^$(Machine)^" -e "s^!OS!^$(OS)^" \ > + -e "s^!CFLAGS!^$(CCFLAGS)^" -e "s^!CC!^$(CC)^" \ > + -e "s^!RELEASE!^$(Version)^" -e "s^!PATCHLEVEL!^$(PatchLevel)^" \ > + -e "s^!MACHTYPE!^$(MACHTYPE)^" -e "s^!RELSTATUS!^$(RELSTATUS)^" \ >$(SUPPORT_SRC)bashbug.sh > $@ > @chmod a+rx bashbug using ^ as an anchor doesn't seem that much better than % autoconf uses & and |, but they tend to do it for vars where it's unlikely those will show up (like path vars) how about something like: @s=$$(printf '\001'); \ sed -e "s$$s!MACHINE!$$s$(Machine)$$s" ... -mike signature.asc Description: Digital signature
Re: popd controlled free (Segmentation fault) with bash 4.2.47, 4.3.48, and 4.4.5
On 21 Nov 2016 10:13, Chet Ramey wrote: > On 11/21/16 6:47 AM, wer...@suse.de wrote: > > Bash Version: 4.2.47, 4.3.48, 4.4.5 > > Release Status: release > > OpenSUSE bug: 1010845 > > CVE: 2016-9401 > > > > Description: > > popd controlled free (Segmentation fault) in all bash versions here > > around > > This has been fixed for a couple of weeks in the devel branch. can you cut a patch ? -mike signature.asc Description: Digital signature
Re: [PATCH 5/5] evalstring: drop volatile on sigset
On 11 Aug 2016 11:45, Chet Ramey wrote: > On 8/11/16 8:30 AM, Mike Frysinger wrote: > > These variables are located on the stack and are never read/written > > directly by bash. Instead, they're all accessed indirectly via the > > POSIX signal API. Since POSIX does not require volatile, and bash > > itself doesn't require volatile, drop the volatile markings. If we > > don't, you get a lot of warnings at build time as the POSIX API does > > not declare the prototypes with a volatile type. > > I want the values usable across a potential longjmp() regardless of what > the compiler does and regardless of the underlying sigset_t type. ISO C > says the value is technically undefined after a longjmp, however unlikely > it is that it will be modified. volatile is the easiest way to accomplish > that. then can casts be added ? building the code w/warnings is fairly verbose due to this issue (generates like ~30 lines of warnings iirc). -mike signature.asc Description: Digital signature
Re: segfault w/bash-4.4-beta2 and assigning empty $*
On 11 Aug 2016 08:32, Chet Ramey wrote: > On 8/11/16 8:29 AM, Mike Frysinger wrote: > > simple code to reproduce: > > bash -c 'v=$*' > > http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html thanks ... still catching up after vacation and hadn't made it that far yet ;) -mike signature.asc Description: Digital signature
[PATCH 1/5] eaccess: constify path arguments
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
externs.h| 2 +-
lib/glob/glob.c | 2 +-
lib/sh/eaccess.c | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/externs.h b/externs.h
index f2b43c415200..fa0603d34657 100644
--- a/externs.h
+++ b/externs.h
@@ -305,7 +305,7 @@ extern int sh_setlinebuf __P((FILE *));
#endif
/* declarations for functions defined in lib/sh/shaccess.c */
-extern int sh_eaccess __P((char *, int));
+extern int sh_eaccess __P((const char *, int));
/* declarations for functions defined in lib/sh/shmatch.c */
extern int sh_regmatch __P((const char *, const char *, int));
diff --git a/lib/glob/glob.c b/lib/glob/glob.c
index c6d7c05dca23..7f6eafe7d2eb 100644
--- a/lib/glob/glob.c
+++ b/lib/glob/glob.c
@@ -84,7 +84,7 @@ struct globval
};
extern void throw_to_top_level __P((void));
-extern int sh_eaccess __P((char *, int));
+extern int sh_eaccess __P((const char *, int));
extern char *sh_makepath __P((const char *, const char *, int));
extern int signal_is_pending __P((int));
extern void run_pending_traps __P((void));
diff --git a/lib/sh/eaccess.c b/lib/sh/eaccess.c
index 8132a9ab50de..8fd8a43e780d 100644
--- a/lib/sh/eaccess.c
+++ b/lib/sh/eaccess.c
@@ -53,9 +53,9 @@ extern int errno;
#endif /* R_OK */
static int path_is_devfd __P((const char *));
-static int sh_stataccess __P((char *, int));
+static int sh_stataccess __P((const char *, int));
#if HAVE_DECL_SETREGID
-static int sh_euidaccess __P((char *, int));
+static int sh_euidaccess __P((const char *, int));
#endif
static int
@@ -135,7 +135,7 @@ sh_stat (path, finfo)
executable. This version uses stat(2). */
static int
sh_stataccess (path, mode)
- char *path;
+ const char *path;
int mode;
{
struct stat st;
@@ -172,7 +172,7 @@ sh_stataccess (path, mode)
the effective and real uid and gid as appropriate. */
static int
sh_euidaccess (path, mode)
- char *path;
+ const char *path;
int mode;
{
int r, e;
@@ -197,7 +197,7 @@ sh_euidaccess (path, mode)
int
sh_eaccess (path, mode)
- char *path;
+ const char *path;
int mode;
{
int ret;
--
2.9.0
[PATCH 4/5] tmpfile: fix pointer cast warning
On systems where sizeof(void*) != sizeof(unsigned int) (e.g. on most 64-bit platforms), we get a warning like so: tmpfile.c: In function 'sh_seedrand': tmpfile.c:128:61: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] srandom (tv.tv_sec ^ tv.tv_usec ^ (getpid () << 16) ^ (unsigned int)&d); Use the standard uintptr_t to turn the pointer into an integer. --- lib/sh/tmpfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/sh/tmpfile.c b/lib/sh/tmpfile.c index 7c2fbf22fbe6..e41e45bd7cac 100644 --- a/lib/sh/tmpfile.c +++ b/lib/sh/tmpfile.c @@ -125,7 +125,7 @@ sh_seedrand () struct timeval tv; gettimeofday (&tv, NULL); - srandom (tv.tv_sec ^ tv.tv_usec ^ (getpid () << 16) ^ (unsigned int)&d); + srandom (tv.tv_sec ^ tv.tv_usec ^ (getpid () << 16) ^ (uintptr_t)&d); seeded = 1; } #endif -- 2.9.0
[PATCH 2/5] general: constify name/file funcs
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
general.c | 26 +-
general.h | 18 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/general.c b/general.c
index 75dda55c3371..d1d37299f8d7 100644
--- a/general.c
+++ b/general.c
@@ -154,9 +154,9 @@ print_rlimtype (n, addnl)
/* Return non-zero if all of the characters in STRING are digits. */
int
all_digits (string)
- char *string;
+ const char *string;
{
- register char *s;
+ register const char *s;
for (s = string; *s; s++)
if (DIGIT (*s) == 0)
@@ -211,9 +211,9 @@ legal_number (string, result)
digit. */
int
legal_identifier (name)
- char *name;
+ const char *name;
{
- register char *s;
+ register const char *s;
unsigned char c;
if (!name || !(c = *name) || (legal_variable_starter (c) == 0))
@@ -234,7 +234,7 @@ legal_identifier (name)
not used in assignments. */
int
valid_nameref_value (name, flags)
- char *name;
+ const char *name;
int flags;
{
if (name == 0 || *name == 0)
@@ -265,7 +265,7 @@ check_selfref (name, value, flags)
#if defined (ARRAY_VARS)
if (valid_array_reference (value, 0))
{
- t = array_variable_name (value, (int *)NULL, (int *)NULL);
+ t = array_variable_name (value, NULL, NULL);
if (t && STREQ (name, t))
{
free (t);
@@ -309,7 +309,7 @@ check_identifier (word, check_word)
used yet. */
int
importable_function_name (string, len)
- char *string;
+ const char *string;
size_t len;
{
if (absolute_program (string)) /* don't allow slash */
@@ -323,7 +323,7 @@ importable_function_name (string, len)
int
exportable_function_name (string)
- char *string;
+ const char *string;
{
if (absolute_program (string))
return 0;
@@ -337,10 +337,10 @@ exportable_function_name (string)
parser (which disqualifies them from alias expansion anyway) and `/'. */
int
legal_alias_name (string, flags)
- char *string;
+ const char *string;
int flags;
{
- register char *s;
+ register const char *s;
for (s = string; *s; s++)
if (shellbreak (*s) || shellxquote (*s) || shellexp (*s) || (*s == '/'))
@@ -627,7 +627,7 @@ sh_closepipe (pv)
int
file_exists (fn)
- char *fn;
+ const char *fn;
{
struct stat sb;
@@ -636,7 +636,7 @@ file_exists (fn)
int
file_isdir (fn)
- char *fn;
+ const char *fn;
{
struct stat sb;
@@ -645,7 +645,7 @@ file_isdir (fn)
int
file_iswdir (fn)
- char *fn;
+ const char *fn;
{
return (file_isdir (fn) && sh_eaccess (fn, W_OK) == 0);
}
diff --git a/general.h b/general.h
index ba7e96878e57..645c8402772f 100644
--- a/general.h
+++ b/general.h
@@ -283,15 +283,15 @@ extern RLIMTYPE string_to_rlimtype __P((char *));
extern void print_rlimtype __P((RLIMTYPE, int));
#endif
-extern int all_digits __P((char *));
+extern int all_digits __P((const char *));
extern int legal_number __P((const char *, intmax_t *));
-extern int legal_identifier __P((char *));
-extern int importable_function_name __P((char *, size_t));
-extern int exportable_function_name __P((char *));
+extern int legal_identifier __P((const char *));
+extern int importable_function_name __P((const char *, size_t));
+extern int exportable_function_name __P((const char *));
extern int check_identifier __P((WORD_DESC *, int));
-extern int valid_nameref_value __P((char *, int));
+extern int valid_nameref_value __P((const char *, int));
extern int check_selfref __P((const char *, const char *, int));
-extern int legal_alias_name __P((char *, int));
+extern int legal_alias_name __P((const char *, int));
extern int assignment __P((const char *, int));
extern int sh_unset_nodelay_mode __P((int));
@@ -308,9 +308,9 @@ extern int same_file __P((char *, char *, struct stat *,
struct stat *));
extern int sh_openpipe __P((int *));
extern int sh_closepipe __P((int *));
-extern int file_exists __P((char *));
-extern int file_isdir __P((char *));
-extern int file_iswdir __P((char *));
+extern int file_exists __P((const char *));
+extern int file_isdir __P((const char *));
+extern int file_iswdir __P((const char *));
extern int path_dot_or_dotdot __P((const char *));
extern int absolute_pathname __P((const char *));
extern int absolute_program __P((const char *));
--
2.9.0
[PATCH 3/5] arrayfunc: constify array names
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
arrayfunc.c | 18 ++
arrayfunc.h | 12 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arrayfunc.c b/arrayfunc.c
index fb87112281d8..eca6e03a642e 100644
--- a/arrayfunc.c
+++ b/arrayfunc.c
@@ -48,7 +48,7 @@ static SHELL_VAR *assign_array_element_internal
__P((SHELL_VAR *, char *, char *
static char *quote_assign __P((const char *));
static void quote_array_assignment_chars __P((WORD_LIST *));
-static char *array_value_internal __P((char *, int, int, int *, arrayind_t *));
+static char *array_value_internal __P((const char *, int, int, int *,
arrayind_t *));
/* Standard error message to use when encountering an invalid array subscript
*/
const char * const bash_badsub_errmsg = N_("bad array subscript");
@@ -881,7 +881,7 @@ print_assoc_assignment (var, quoted)
/* Return 1 if NAME is a properly-formed array reference v[sub]. */
int
valid_array_reference (name, flags)
- char *name;
+ const char *name;
int flags;
{
char *t;
@@ -948,7 +948,8 @@ array_expand_index (var, s, len)
in *LENP. This returns newly-allocated memory. */
char *
array_variable_name (s, subp, lenp)
- char *s, **subp;
+ const char *s;
+ char **subp;
int *lenp;
{
char *t, *ret;
@@ -992,7 +993,8 @@ array_variable_name (s, subp, lenp)
If LENP is non-null, the length of the subscript is returned in *LENP. */
SHELL_VAR *
array_variable_part (s, subp, lenp)
- char *s, **subp;
+ const char *s;
+ char **subp;
int *lenp;
{
char *t;
@@ -1029,7 +1031,7 @@ array_variable_part (s, subp, lenp)
reference is name[@], and 0 otherwise. */
static char *
array_value_internal (s, quoted, flags, rtype, indp)
- char *s;
+ const char *s;
int quoted, flags, *rtype;
arrayind_t *indp;
{
@@ -1149,7 +1151,7 @@ array_value_internal (s, quoted, flags, rtype, indp)
subscript contained in S, obeying quoting for subscripts * and @. */
char *
array_value (s, quoted, flags, rtype, indp)
- char *s;
+ const char *s;
int quoted, flags, *rtype;
arrayind_t *indp;
{
@@ -1162,7 +1164,7 @@ array_value (s, quoted, flags, rtype, indp)
evaluator in expr.c. */
char *
get_array_value (s, flags, rtype, indp)
- char *s;
+ const char *s;
int flags, *rtype;
arrayind_t *indp;
{
@@ -1171,7 +1173,7 @@ get_array_value (s, flags, rtype, indp)
char *
array_keys (s, quoted)
- char *s;
+ const char *s;
int quoted;
{
int len;
diff --git a/arrayfunc.h b/arrayfunc.h
index 3a29a594e98e..46bf2c70f024 100644
--- a/arrayfunc.h
+++ b/arrayfunc.h
@@ -58,14 +58,14 @@ extern void print_array_assignment __P((SHELL_VAR *, int));
extern void print_assoc_assignment __P((SHELL_VAR *, int));
extern arrayind_t array_expand_index __P((SHELL_VAR *, char *, int));
-extern int valid_array_reference __P((char *, int));
-extern char *array_value __P((char *, int, int, int *, arrayind_t *));
-extern char *get_array_value __P((char *, int, int *, arrayind_t *));
+extern int valid_array_reference __P((const char *, int));
+extern char *array_value __P((const char *, int, int, int *, arrayind_t *));
+extern char *get_array_value __P((const char *, int, int *, arrayind_t *));
-extern char *array_keys __P((char *, int));
+extern char *array_keys __P((const char *, int));
-extern char *array_variable_name __P((char *, char **, int *));
-extern SHELL_VAR *array_variable_part __P((char *, char **, int *));
+extern char *array_variable_name __P((const char *, char **, int *));
+extern SHELL_VAR *array_variable_part __P((const char *, char **, int *));
#else
--
2.9.0
[PATCH 5/5] evalstring: drop volatile on sigset
These variables are located on the stack and are never read/written directly by bash. Instead, they're all accessed indirectly via the POSIX signal API. Since POSIX does not require volatile, and bash itself doesn't require volatile, drop the volatile markings. If we don't, you get a lot of warnings at build time as the POSIX API does not declare the prototypes with a volatile type. --- builtins/evalstring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtins/evalstring.c b/builtins/evalstring.c index 66926e9228d6..5c62a584fafa 100644 --- a/builtins/evalstring.c +++ b/builtins/evalstring.c @@ -231,7 +231,7 @@ parse_and_execute (string, from_file, flags) int code, lreset; volatile int should_jump_to_top_level, last_result; COMMAND *volatile command; - volatile sigset_t pe_sigmask; + sigset_t pe_sigmask; parse_prologue (string, flags, PE_TAG); @@ -488,7 +488,7 @@ parse_string (string, from_file, flags, endp) volatile int should_jump_to_top_level; COMMAND *volatile command, *oglobal; char *ostring; - volatile sigset_t ps_sigmask; + sigset_t ps_sigmask; parse_prologue (string, flags, PS_TAG); -- 2.9.0
segfault w/bash-4.4-beta2 and assigning empty $*
simple code to reproduce: bash -c 'v=$*' gdb backtrace: Program received signal SIGSEGV, Segmentation fault. quote_string (string=0x0) at subst.c:3940 3940 if (*string == 0) #0 quote_string (string=0x0) at subst.c:3940 #1 0x0045c052 in param_expand (string=string@entry=0x7237c0 "$*", sindex=sindex@entry=0x7fffc43c, quoted=quoted@entry=0x0, expanded_something=expanded_something@entry=0x0, contains_dollar_at=contains_dollar_at@entry=0x7fffc448, quoted_dollar_at_p=quoted_dollar_at_p@entry=0x7fffc440, had_quoted_null_p=0x7fffc444, pflags=0x8) at subst.c:8570 #2 0x0045ca34 in expand_word_internal (word=word@entry=0x7fffc4e0, quoted=quoted@entry=0x0, isexp=isexp@entry=0x0, contains_dollar_at=contains_dollar_at@entry=0x0, expanded_something=expanded_something@entry=0x0) at subst.c:9194 #3 0x0045e3ac in call_expand_word_internal (w=w@entry=0x7fffc4e0, q=q@entry=0x0, i=i@entry=0x0, c=c@entry=0x0, e=0x0) at subst.c:3555 #4 0x0045e50a in expand_string_assignment (string=string@entry=0x7237a2 "$*", quoted=quoted@entry=0x0) at subst.c:3643 #5 0x004577de in expand_string_if_necessary (string=string@entry=0x7237a2 "$*", quoted=quoted@entry=0x0, func=func@entry=0x45e4a0 ) at subst.c:3345 #6 0x00457c8f in do_assignment_internal (word=0x723740, expand=expand@entry=0x1) at subst.c:3073 #7 0x00460265 in do_word_assignment (flags=0x0, word=) at subst.c:3162 #8 expand_word_list_internal (list=, eflags=eflags@entry=0x1f) at subst.c:10543 #9 0x0046056a in expand_words (list=) at subst.c:10098 #10 0x004381cf in execute_simple_command (simple_command=, pipe_in=, pipe_in@entry=0x, pipe_out=pipe_out@entry=0x, async=async@entry=0x0, fds_to_close=fds_to_close@entry=0x7235f0) at execute_cmd.c:4132 #11 0x0043a24a in execute_command_internal (command=0x723580, asynchronous=asynchronous@entry=0x0, pipe_in=pipe_in@entry=0x, pipe_out=pipe_out@entry=0x, fds_to_close=fds_to_close@entry=0x7235f0) at execute_cmd.c:802 #12 0x0048190f in parse_and_execute (string=, from_file=from_file@entry=0x4c1d69 "-c", flags=flags@entry=0x4) at evalstring.c:424 #13 0x0041f60e in run_one_command (command=) at shell.c:1399 #14 0x0042111f in main (argc=0x3, argv=0x7fffcbc8, env=0x7fffcbe8) at shell.c:724 -mike signature.asc Description: Digital signature
[PATCH] include ctype.h for isdigit usage
--- lib/readline/histexpand.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/readline/histexpand.c b/lib/readline/histexpand.c index 46a99aa62e30..13248db83048 100644 --- a/lib/readline/histexpand.c +++ b/lib/readline/histexpand.c @@ -26,6 +26,7 @@ #endif #include +#include #if defined (HAVE_STDLIB_H) # include -- 2.9.0
Re: Bash-4.4-beta2 available for download
On 12 Jul 2016 21:38, Chet Ramey wrote: > +== CHANGES ==+ > This document details the changes between this version, bash-4.4-beta2, and > the previous version, bash-4.4-rc1. why back to beta ? generally "rc" is considered newer than "beta", and the previous bash-4.4 releases were following that: readline-7.0-beta.tar.gz Mon, 12 Oct 2015 13:37:21 GMT readline-7.0-rc1.tar.gz Tue, 23 Feb 2016 19:02:49 GMT bash-4.4-beta.tar.gz Mon, 12 Oct 2015 13:39:30 GMT bash-4.4-rc1.tar.gz Tue, 23 Feb 2016 19:02:26 GMT bash-4.4-beta2.tar.gz Mon, 11 Jul 2016 14:11:37 GMT -mike signature.asc Description: Digital signature
Re: avoid mktemp/mkstemp internally
On 19 May 2016 14:37, Chet Ramey wrote: > On 5/16/16 10:36 AM, Mike Frysinger wrote: > >> Because many traditional implementations of mktemp/mkstemp suck. > > > > and many modern implementations work perfectly fine. why is the default > > to penalize good/fixed versions ? how about we flip this in config-top.h > > like the attached patch ? > > Yes, we'll try that with correct names. See what happens. > > >>> the bash versions seem like it's pretty trivial to collide: it mixes > >>> current seconds count, current pid number, and a counter. > >> > >> Not quite; the calls in bash mix in the return value from the system's > >> random(). Now, if that sucks too, you're going to lose. > > > > except bash isn't calling srand anywhere that i can see, so you're > > iterating over the same values every time. > > Good catch, except you mean srandom(). I'll add in a call to that for the > fallback code. ah, yes, you're using random(), so srandom() is the right init. thanks! -mike signature.asc Description: Digital signature
Re: avoid mktemp/mkstemp internally
On 16 May 2016 10:02, Chet Ramey wrote: > On 5/13/16 2:40 PM, Mike Frysinger wrote: > > i was pointed at a bug report for FreeBSD systems [1] where running lots > > of processes in parallel would randomly fail with errors like: > > cannot make pipe for process substitution: File exists > > > > upstream FreeBSD addressed this by defining USE_MKTEMP [2] & USE_MKSTEMP > > [3] when building bash. looking at the source in bash though, i can't > > see why these aren't always defined. why does bash try to reimplement > > both funcs ad-hoc instead of just using the stable/guaranteed system > > versions ? > > Because many traditional implementations of mktemp/mkstemp suck. and many modern implementations work perfectly fine. why is the default to penalize good/fixed versions ? how about we flip this in config-top.h like the attached patch ? > > the bash versions seem like it's pretty trivial to collide: it mixes > > current seconds count, current pid number, and a counter. > > Not quite; the calls in bash mix in the return value from the system's > random(). Now, if that sucks too, you're going to lose. except bash isn't calling srand anywhere that i can see, so you're iterating over the same values every time. i'm not sure how this implementation wouldn't also fall into the "inferior" bucket. -mike --- a/config-top.h +++ b/config-top.h @@ -152,3 +152,9 @@ /* Define to the maximum level of recursion you want for the source/. builtin. 0 means the limit is not active. */ #define SOURCENEST_MAX 0 + +/* Define if your mktemp implementation is sane. */ +#define USE_MKTEMP + +/* Define if your mkstemp implementation is sane. */ +#define USE_MKTEMP signature.asc Description: Digital signature
Re: Cannot clone from anonymous git
On 13 May 2016 15:42, Eduardo A. Bustamante López wrote: > http://savannah.gnu.org/git/?group=bash lists: > > | Getting a Copy of the Git Repository > | > | Anonymous clone: > | > | git clone git://git.savannah.gnu.org/bash.git > | > | Member clone: > | > | git clone @git.sv.gnu.org:/srv/git/bash.git > > When I try to clone: > > | dualbus@hp ~ % git clone git://git.savannah.gnu.org/bash.git > | Cloning into 'bash'... > | fatal: Could not read from remote repository. > | > | Please make sure you have the correct access rights > | and the repository exists. > > The links here appear to work: http://git.savannah.gnu.org/cgit/bash.git savannah in general is having troubles. pretty sure there's not much bash can do but wait for them to resolve things. -mike signature.asc Description: Digital signature
avoid mktemp/mkstemp internally
i was pointed at a bug report for FreeBSD systems [1] where running lots of processes in parallel would randomly fail with errors like: cannot make pipe for process substitution: File exists upstream FreeBSD addressed this by defining USE_MKTEMP [2] & USE_MKSTEMP [3] when building bash. looking at the source in bash though, i can't see why these aren't always defined. why does bash try to reimplement both funcs ad-hoc instead of just using the stable/guaranteed system versions ? the bash versions seem like it's pretty trivial to collide: it mixes current seconds count, current pid number, and a counter. when you factor in modern tech like linux pid namespaces, it's trivial to get a situation where the pid/time are the same values. -mike [1] https://bugs.gentoo.org/574426 [2] https://svnweb.freebsd.org/ports?view=revision&revision=391614 [3] https://svnweb.freebsd.org/ports?view=revision&revision=391692 signature.asc Description: Digital signature
Re: Avoid asterisk expansion when it selects "everything"
On 14 Apr 2016 09:23, Andreas Schwab wrote: > Mike Frysinger writes: > > alternative idea: alias your rm/mv/etc... commands if you're worried > > about them. it's not uncommon to do in ~/.bashrc or wherever: > > alias rm='rm -i' > > That's the worst advice you can give. hyperbole much ? > If you lose the alias for whatever reason you get silent failure. you mean you get the status quo. oh no! -mike signature.asc Description: Digital signature
Re: Avoid asterisk expansion when it selects "everything"
On 13 Apr 2016 11:23, Anis ELLEUCH wrote: > I would like to ask if it is possible to disable expanding asterisk when it > selects all entries ? > > `$ rm * .jpg` with a mistaken space between asterisk and .jpg will delete > everything in your home directory or in the entire disk. > > In my opinion, when the user asks to select "everything" which could be `*` > or `path/*`, bash has to show a confirmation prompt to check if the user > was not mistaken, this option should be obviously disabled by default > > Another idea: `*` and `/*` should not be interpreted and the user has to > enter another sequence "more powerful" to emphasize selecting all entries ( > `^*` would it work just fine ?) alternative idea: alias your rm/mv/etc... commands if you're worried about them. it's not uncommon to do in ~/.bashrc or wherever: alias rm='rm -i' then it's safe to `rm * .jpg`. for example: $ alias rm='rm -i' $ rm * rm: remove regular file ‘aaa’? ^C -mike signature.asc Description: Digital signature
[patch] fix misc warnings
the fixes below cover specific warnings. but there's more i wasn't able to fix.
seems like this should be easy ... but iirc i've reported it before ...
expr.c:210:17: warning: conflicting types for built-in function ‘exp2’
static intmax_t exp2 __P((void));
there's some weirdness with the nested ifdefs around the decl in externs.h:
subst.c: In function ‘process_substitute’:
subst.c:5774:5: warning: implicit declaration of function ‘fpurge’
[-Wimplicit-function-declaration]
fpurge (stdout);
i'm guessing you don't care about the volatile warnings:
execute_cmd.c: In function ‘execute_function’:
execute_cmd.c:4658:16: warning: assignment discards ‘volatile’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
fa->source_a = bash_source_a;
execute_cmd.c:4660:16: warning: assignment discards ‘volatile’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
fa->lineno_a = bash_lineno_a;
evalstring.c: In function ‘parse_and_execute’:
evalstring.c:239:16: warning: passing argument 1 of ‘sigemptyset’ discards
‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]
sigemptyset (&pe_sigmask);
and here's the ones i did fix.
=
execute_cmd.c: In function ‘coproc_pidchk’:
execute_cmd.c:2119:1: warning: type of ‘status’ defaults to ‘int’
[-Wimplicit-int]
coproc_pidchk (pid, status)
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -2118,6 +2118,7 @@ coproc_fdrestore (cp)
void
coproc_pidchk (pid, status)
pid_t pid;
+ int status;
{
struct coproc *cp;
=
/usr/homes/chet/src/bash/src/parse.y: In function ‘shell_getc’:
/usr/homes/chet/src/bash/src/parse.y:2315:24: warning: format ‘%llu’ expects
argument of type ‘long long unsigned int’, but argument 3 has type ‘long
unsigned int’ [-Wformat=]
--- a/parse.y
+++ b/parse.y
@@ -2312,7 +2312,7 @@ shell_getc (remove_quoted_newline)
if (n <= 2) /* we have to save 1 for the newline added
below */
{
if (truncating == 0)
- internal_warning("shell_getc: shell_input_line_size (%zu)
exceeds SIZE_MAX (%llu): line truncated", shell_input_line_size, (unsigned
long)SIZE_MAX);
+ internal_warning("shell_getc: shell_input_line_size (%zu)
exceeds SIZE_MAX (%u): line truncated", shell_input_line_size, SIZE_MAX);
shell_input_line[i] = '\0';
truncating = 1;
}
=
subst.c: In function ‘skip_double_quoted’:
subst.c:975:1: warning: type of ‘flags’ defaults to ‘int’ [-Wimplicit-int]
skip_double_quoted (string, slen, sind, flags)
--- a/subst.c
+++ b/subst.c
@@ -976,6 +976,7 @@ skip_double_quoted (string, slen, sind, flags)
char *string;
size_t slen;
int sind;
+ int flags;
{
int c, i;
char *ret;
=
jobs.c: In function ‘get_original_tty_job_signals’:
jobs.c:2130:4: warning: implicit declaration of function ‘set_original_signal’
[-Wimplicit-function-declaration]
set_original_signal (SIGTSTP, SIG_DFL);
--- a/trap.h
+++ b/trap.h
@@ -22,6 +22,7 @@
#define _TRAP_H_
#include "stdc.h"
+#include "sig.h"
#if !defined (SIG_DFL)
#include "bashtypes.h"
@@ -95,6 +96,7 @@ extern void restore_original_signals __P((void));
extern void get_original_signal __P((int));
extern void get_all_original_signals __P((void));
+extern void set_original_signal __P((int, SigHandler *));
extern char *signal_name __P((int));
-mike
signature.asc
Description: Digital signature
Re: How to lock a terminal
On 16 Feb 2016 18:19, Bob Proulx wrote: > Nick Warne wrote: > > I was in a SSH session, and checking something inadvertently issued: > > > > > nano /var/log/messages | grep a > > > > (I was searching for something else than an 'a', but the above example shows > > the issue - about to use 'nano', but then forgot to change it to 'cat'). > > > > The terminal just sits there doing nothing - CTRL+C doesn't do anything; in > > a SSH session, the only option is to kill the terminal. On a local machine, > > you can use kill -9 from another terminal to get out of it. > > On a remote machine you can do the same. There really is no > difference between local and remote here. You just use a second > terminal for it. > > However this is the perfect case for job control. No need for a > second terminal. Here is an example. Use Control-Z to stop the > foreground job. sometimes ^Z doesn't work once nano starts up. probably should add isatty checking to nano itself. -mike signature.asc Description: Digital signature
Re: bug when 'cd ..' to a directory who's parent has been deleted
On 09 Feb 2016 07:47, Chet Ramey wrote: > On 2/9/16 2:10 AM, Mike Frysinger wrote: > >> It's still an unlikely scenario. > > > > fwiw, i see it semi often when dealing with build systems: > > The unlikely scenario is somehow deleting a non-empty directory, as the OP > implied in his first posting. i'm aware of how it's happening. my point is that it's not completely unheard of, so i cited the real world cases where it comes up. and at least for me, on a semi-regular basis. -mike signature.asc Description: Digital signature
Re: bug when 'cd ..' to a directory who's parent has been deleted
On 09 Feb 2016 12:22, Odd Beck wrote:
> We all use our number crunching slaves differently, so I have never seen it
> until yesterday, but if it's common then there might be a valid reason to
> investigate this issue and maybe do some bugfixin' :)
sorry, but my posting wasn't to say i think the current behavior in bash
is wrong. i agree w/Chet that when you try to do `cd ..` in a dir that
has been disconnected from the active filesystem namespace, the behavior
is largely to be expected. If $PWD has no actual parent, then you'll
get errors. Falling back to ${PWD%/*} might be nice, but even then it
would be superficial until you managed to get back to the actual fs.
-mike
signature.asc
Description: Digital signature
Re: bug when 'cd ..' to a directory who's parent has been deleted
On 08 Feb 2016 10:38, Chet Ramey wrote:
> On 2/8/16 10:36 AM, Andreas Schwab wrote:
> > Chet Ramey writes:
> >> On 2/8/16 9:59 AM, Andreas Schwab wrote:
> >>> Chet Ramey writes:
> >>>
> `cd ..' should fail, since the parent no longer exists, and the pathname
> canonicalization should fail, since there's presumably no longer a valid
> path to reach the current directory. No value for $PWD is correct.
> >>>
> >>> ${PWD%/*} would be a reasonable value. FWIW, this is what ksh uses in
> >>> this case, it doesn't fail.
> >>
> >> Why would that be more reasonable than anything else? It references a
> >> path that doesn't exist.
> >
> > Sorry, I misread the OP's message. I didn't notice it's about the
> > parent's parent, not the parent.
>
> It's still an unlikely scenario.
fwiw, i see it semi often when dealing with build systems:
- use a package manager to build a package
- PM creates a fresh new dir tree to build/install
- build fails for whatever reason
- go into that directory tree (usually multiple levels)
- figure out problem
- fix it in a diff window
- re-run the PM command to build the package in shell in build tree
- that shell's active tree is now gone and you get shell-init errors
just google "shell-init error retrieving current directory" to see
many other people randomly running into it as well.
i see it weekly, but i know what's going on, and i build a lot of
code. so is it "unlikely" ? i guess in the larger scheme of things
compared it might be, but i wouldn't say it's so unlikely that a user
would never see it.
-mike
signature.asc
Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 15 Dec 2015 06:47, konsolebox wrote: > t On Mon, Dec 14, 2015 at 1:17 PM, Mike Frysinger wrote: > > On 13 Dec 2015 16:50, konsolebox wrote: > >> On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote: > >> > Today, if you have a script that lives on a noexec mount point, the > >> > kernel will reject attempts to run it directly: > >> > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh > >> > $ chmod a+rx /dev/shm/test.sh > >> > $ /dev/shm/test.sh > >> > bash: /dev/shm/test.sh: Permission denied > >> > > >> > But bash itself has no problem running this file: > >> > $ bash /dev/shm/test.sh > >> > hi > >> > Or with letting other scripts run this file: > >> > $ bash -c '. /dev/shm/test.sh' > >> > hi > >> > Or with reading the script from stdin: > >> > $ bash >> > hi > >> > > >> > This detracts from the security of the overall system. People writing > >> > scripts sometimes want to save/restore state (s) and will > >> > restore the content from a noexec point using the aforementioned source > >> > command without realizing that it executes code too. Of course their > >> > code is wrong, but it would be nice if the system would catch & reject > >> > it explicitly to stave of inadvertent usage. > >> > > >> > This is not a perfect solution as it can still be worked around by > >> > inlining the code itself: > >> > $ bash -c "$(cat /dev/shm/test.sh)" > >> > hi > >> > > >> > But this makes things a bit harder for malicious attackers (depending > >> > how exactly they've managed to escalate), but it also helps developers > >> > from getting it wrong in the first place. > >> > >> Application-level based security on an environment where people using > >> the application has direct control over the environment for me is not > >> so sensible, and is a dirty hack. A shell is also not meant for that. > >> If you want such feature perhaps you should add it on a restricted > >> shell, granting it really makes sense adding it. But forcing that > >> feature to be default on every user (like me who doesn't want its > >> inconsistency) is wrong. A shell reads and executes and is something > >> not in the scope of `noexec`, not in the scope of kernel-land > >> security, so we have to deal with it. > > > > (1) the examples i already provided do not involve the user at all, and > > include systems where the user has no direct access to the shell. > > And the one that made the code execute remotely through for example an > exploit is not a user? you're conflating concepts, but still, the answer is no. having a user sitting at an interactive terminal and typing in commands or getting the system to directly execute bash is not what i described. systems that do not permit access to any shells anywhere, and instead the attack is breaking out of one process to write a text file somewhere that a diff system/periodic process will later source. you could get the same setup as having a system you can only access over HTTP (i.e. no shell access) and exploiting apache/php/whatever to write to a cache file that will be read by another app. i recall some router firmwares being attacked in this way -- a remote bug only permitted the writing of data to common data locations, but they picked a place where privileged init scripts would source saved state. > Also consider use of `source` or `eval` may it be in a subshell or not. these cases have already been cited in this thread, and still are not relevant to the scenarios described > > (2) choice over runtime functionality is by the sysadmin, not the user. > > Doesn't matter to me. And I'm referring to the real user or the > person, and not the account. I don't want an inconsistent > functionality running in my bash whether I'm using a privileged > account or not. it isn't inconsistent: no user gets to exec code from noexec points > > (3) i disagree over the scope of noexec. i think this is in-scope. > > Being a little forgiving, I could say that scripts with #! headers > -perhaps- are still in the scope of `noexec` since they are respected > by the kernel as executables, even though they are not real > instructions running within the processor's transistors themselves > (they are just read and -virtually- executed where the shell acts on > behalf of them), but how about those scripts without #! headers? &g
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 13 Dec 2015 17:24, Chet Ramey wrote: > On 12/12/15 4:01 PM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh > > $ chmod a+rx /dev/shm/test.sh > > $ /dev/shm/test.sh > > bash: /dev/shm/test.sh: Permission denied > > > > But bash itself has no problem running this file: > > It's hard to see how this proposal improves overall system security. There > are a dozen ways a minimally-competent attacker can circumvent it. you're assuming the attacker has unlimited access to resources and control over the environment and execution. i already noted there are ways to run arbitrary code -- when you have arbitrary code access. there also are cases (such as i described) which this change would block attacks because the attacker does not have such unfettered access. they're leveraging a small bug elsewhere to escalate to a fuller environment. > Unless > you want to completely remove the ability for bash and other utilities to > read files from a noexec file system, or run on a system with no writable > file systems at all, this does no good. Its primary effect would seem to > be annoying and frustrating users. > > A worse problem is that the abstraction is in the wrong place. The shell, > like other programs, requests services from the kernel to do things. The > kernel is the arbiter of restrictions on those services. If asked to > execute a file, the shell asks the kernel whether the file is executable, > then tries to execute it. If asked to read a file, the shell tries to > open it. The kernel, or some agent it invokes, is where the access > decision is made. If you want to, for instance, disallow the shell and > other utilities from opening executable files for reading on file systems > with noexec set, the shell binary is not the place to embed that policy. i'm aware of the fundamental structure of UNIX-like systems. bash itself is providing services to a program by executing the requested code and in a sense, has a responsibility to control that. otherwise, you seem to be arguing against the existence of rbash, or job control, or similar shell limiting/control functionality. i understand this is a disruptive change. how about making it a compile time flag, or perhaps a new shopt ? -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 13 Dec 2015 12:21, Piotr Grzybowski wrote: > On Sat, Dec 12, 2015 at 11:53 PM, Mike Frysinger wrote: > > On 12 Dec 2015 15:06, Bob Proulx wrote: > >> It will almost > >> certainly get in the way of a reasonable use case. > > > > can you name a reasonable use case this breaks ? > > source /media/noexecmountpoint/sh/functions.sh; > find_all_files_with_executable_bit /media/noexecmountpoint; i think you're doing it wrong. if you want to run code off of mount point, then you should be mounting it executable. > Mike: I kind of understand your idea, but noexec flag given in the > mount significates something else then your patch addresses. i disagree -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 12 Dec 2015 23:05, Stephane Chazelas wrote: > 2015-12-12 16:01:26 -0500, Mike Frysinger: > [...] > > This is not a perfect solution as it can still be worked around by > > inlining the code itself: > > $ bash -c "$(cat /dev/shm/test.sh)" > > hi > > Or > > cat /dev/shm/test.sh | bash right, there's no way to look through pipes > I think this kind of hardening is better left to things like > selinux/apparmor. security is not an all-or-nothing proposotion. the whole point is to have defence in depth. -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 13 Dec 2015 16:50, konsolebox wrote: > On Sun, Dec 13, 2015 at 5:01 AM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh > > $ chmod a+rx /dev/shm/test.sh > > $ /dev/shm/test.sh > > bash: /dev/shm/test.sh: Permission denied > > > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > > Or with letting other scripts run this file: > > $ bash -c '. /dev/shm/test.sh' > > hi > > Or with reading the script from stdin: > > $ bash > hi > > > > This detracts from the security of the overall system. People writing > > scripts sometimes want to save/restore state (like variables) and will > > restore the content from a noexec point using the aforementioned source > > command without realizing that it executes code too. Of course their > > code is wrong, but it would be nice if the system would catch & reject > > it explicitly to stave of inadvertent usage. > > > > This is not a perfect solution as it can still be worked around by > > inlining the code itself: > > $ bash -c "$(cat /dev/shm/test.sh)" > > hi > > > > But this makes things a bit harder for malicious attackers (depending > > how exactly they've managed to escalate), but it also helps developers > > from getting it wrong in the first place. > > Application-level based security on an environment where people using > the application has direct control over the environment for me is not > so sensible, and is a dirty hack. A shell is also not meant for that. > If you want such feature perhaps you should add it on a restricted > shell, granting it really makes sense adding it. But forcing that > feature to be default on every user (like me who doesn't want its > inconsistency) is wrong. A shell reads and executes and is something > not in the scope of `noexec`, not in the scope of kernel-land > security, so we have to deal with it. (1) the examples i already provided do not involve the user at all, and include systems where the user has no direct access to the shell. (2) choice over runtime functionality is by the sysadmin, not the user. (3) i disagree over the scope of noexec. i think this is in-scope. -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 12 Dec 2015 22:12, John McKown wrote: > On Sat, Dec 12, 2015 at 3:01 PM, Mike Frysinger wrote: > > Today, if you have a script that lives on a noexec mount point, the > > kernel will reject attempts to run it directly: > > $ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh > > $ chmod a+rx /dev/shm/test.sh > > $ /dev/shm/test.sh > > bash: /dev/shm/test.sh: Permission denied > > > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > > Or with letting other scripts run this file: > > $ bash -c '. /dev/shm/test.sh' > > hi > > Or with reading the script from stdin: > > $ bash > hi > > > > This detracts from the security of the overall system. People writing > > scripts sometimes want to save/restore state (like variables) and will > > restore the content from a noexec point using the aforementioned source > > command without realizing that it executes code too. Of course their > > code is wrong, but it would be nice if the system would catch & reject > > it explicitly to stave of inadvertent usage. > > > > This is not a perfect solution as it can still be worked around by > > inlining the code itself: > > $ bash -c "$(cat /dev/shm/test.sh)" > > hi > > > > If this is a bug in BASH, then it is likely also a bug in: Python, PERL, > Ruby, LUA, oorexx, . But, > quite honestly, I haven't checked it out because I don't have a "noexec" > mountpoint handy here at home. i'm aware. it'd make sense in my mind to have all dynamic interpreters detect the source files before attempting to execute them. i'm looking at shells to start with as they're way more common to be installed and to be a target. -mike signature.asc Description: Digital signature
Re: [PATCH/RFC] do not source/exec scripts on noexec mount points
On 12 Dec 2015 15:06, Bob Proulx wrote: > Mike Frysinger wrote: > > But bash itself has no problem running this file: > > $ bash /dev/shm/test.sh > > hi > >... > > This detracts from the security of the overall system. People > > writing scripts sometimes want to save/restore state (like > > variables) and will restore the content from a noexec point using > > the aforementioned source command without realizing that it executes > > code too. Of course their code is wrong, but it would be nice if > > the system would catch & reject it explicitly to stave of > > inadvertent usage. > > I don't think it makes sense for a userland program to be an enforcer > of this type of check. It gives a false impression of a security that > does not exist. Which I think is more dangerous. i disagree, and it's the right place imo: the program that does the interpreting in the first place (i.e. the shell) should be checking for the settings where it's going to be loading that interpreted code. the reason binary loaders (e.g. ELF ldso's) don't need to do this is the kernel either prevents it directly (`./foo`) or indirectly (when the ldso tries to mmap the file with exec bits, the kernel will check for the noexec mount setting). > It will almost > certainly get in the way of a reasonable use case. can you name a reasonable use case this breaks ? > And nothing > prevents one from running a private copy of a shell without such a > check. Or any of the many compatible /bin/sh variants such as ksh, > zsh, ash, dash, and so forth. you're assuming (1) the user has access to a writable && exec mount point and (2) those other shells are installed. clamping both of those loop holes are trivial and i've seen a number of systems that do exactly that. Chrome OS for example only mounts / as executable and that is also read only. i imagine other verified boot systems enforce similar sanity, as do remote hosts (a number of systems i have ssh access do this). i also plan on sending patches for shells i care about (e.g. dash). -mike signature.asc Description: Digital signature
[PATCH/RFC] do not source/exec scripts on noexec mount points
From: Mike Frysinger
Today, if you have a script that lives on a noexec mount point, the
kernel will reject attempts to run it directly:
$ printf '#!/bin/sh\necho hi\n' > /dev/shm/test.sh
$ chmod a+rx /dev/shm/test.sh
$ /dev/shm/test.sh
bash: /dev/shm/test.sh: Permission denied
But bash itself has no problem running this file:
$ bash /dev/shm/test.sh
hi
Or with letting other scripts run this file:
$ bash -c '. /dev/shm/test.sh'
hi
Or with reading the script from stdin:
$ bash
#include
+#if defined (HAVE_SYS_STATVFS_H)
+# include
+#endif
+
#include "../bashansi.h"
#include "../bashintl.h"
@@ -160,6 +164,26 @@ file_error_and_exit:
return ((flags & FEVAL_BUILTIN) ? EXECUTION_FAILURE : -1);
}
+#if defined (HAVE_SYS_STATVFS_H) && defined (ST_NOEXEC)
+ /* If the script is loaded from a noexec mount point, throw an error. */
+ {
+struct statvfs stvfs;
+
+if (fstatvfs (fd, &stvfs) == -1)
+ {
+ close (fd);
+ goto file_error_and_exit;
+ }
+
+if (stvfs.f_flag & ST_NOEXEC)
+ {
+ close (fd);
+ errno = EACCES;
+ goto file_error_and_exit;
+ }
+ }
+#endif
+
if (S_ISREG (finfo.st_mode) && file_size <= SSIZE_MAX)
{
string = (char *)xmalloc (1 + file_size);
diff --git a/config.h.in b/config.h.in
index 894892f..b16f1d6 100644
--- a/config.h.in
+++ b/config.h.in
@@ -1039,6 +1039,9 @@
/* Define if you have the header file. */
#undef HAVE_SYS_STAT_H
+/* Define if you have . */
+#undef HAVE_SYS_STATVFS_H
+
/* Define if you have the header file. */
#undef HAVE_SYS_STREAM_H
diff --git a/configure b/configure
index 52f6f5c..061b15e 100755
--- a/configure
+++ b/configure
@@ -9301,7 +9301,7 @@ fi
done
for ac_header in sys/pte.h sys/stream.h sys/select.h sys/file.h sys/ioctl.h \
-sys/param.h sys/socket.h sys/stat.h \
+sys/param.h sys/socket.h sys/stat.h sys/statvfs.h \
sys/time.h sys/times.h sys/types.h sys/wait.h
do :
as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
diff --git a/configure.ac b/configure.ac
index f0d4aee..81b2a7c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -717,7 +717,7 @@ AC_CHECK_HEADERS(unistd.h stdlib.h stdarg.h varargs.h
limits.h string.h \
stdbool.h stddef.h stdint.h netdb.h pwd.h grp.h strings.h \
regex.h syslog.h ulimit.h)
AC_CHECK_HEADERS(sys/pte.h sys/stream.h sys/select.h sys/file.h sys/ioctl.h \
-sys/param.h sys/socket.h sys/stat.h \
+sys/param.h sys/socket.h sys/stat.h sys/statvfs.h \
sys/time.h sys/times.h sys/types.h sys/wait.h)
AC_CHECK_HEADERS(netinet/in.h arpa/inet.h)
diff --git a/shell.c b/shell.c
index 0e47cf4..4739a31 100644
--- a/shell.c
+++ b/shell.c
@@ -46,6 +46,10 @@
# include
#endif
+#if defined (HAVE_SYS_STATVFS_H)
+# include
+#endif
+
#include "bashintl.h"
#define NEED_SH_SETLINEBUF_DECL/* used in externs.h */
@@ -334,6 +338,8 @@ static void shell_reinitialize __P((void));
static void show_shell_usage __P((FILE *, int));
+static void check_noexec __P((int, const char *));
+
#ifdef __CYGWIN__
static void
_cygwin32_check_tmp ()
@@ -717,6 +723,7 @@ main (argc, argv, env)
{
/* In this mode, bash is reading a script from stdin, which is a
pipe or redirected file. */
+ check_noexec (0, "stdin");
#if defined (BUFFERED_INPUT)
default_buffered_input = fileno (stdin); /* == 0 */
#else
@@ -1442,6 +1449,28 @@ start_debugger ()
#endif
}
+static void
+check_noexec (int fd, const char *filename)
+{
+#if defined (HAVE_SYS_STATVFS_H) && defined (ST_NOEXEC)
+ /* Make sure the file isn't on a noexec mount point. */
+ struct statvfs stvfs;
+
+ if (fstatvfs (fd, &stvfs) == -1)
+{
+ file_error (filename);
+ exit (EX_NOTFOUND);
+}
+
+ if (stvfs.f_flag & ST_NOEXEC)
+{
+ errno = EACCES;
+ file_error (filename);
+ exit (EX_NOEXEC);
+}
+#endif
+}
+
static int
open_shell_script (script_name)
char *script_name;
@@ -1579,6 +1608,8 @@ open_shell_script (script_name)
SET_CLOSE_ON_EXEC (fileno (default_input));
#endif /* !BUFFERED_INPUT */
+ check_noexec (fd, filename);
+
/* Just about the only way for this code to be executed is if something
like `bash -i /dev/stdin' is executed. */
if (interactive_shell && fd_is_tty)
--
2.6.2
Re: bash closes fd twice.
On 11 Dec 2015 07:06, Eric Blake wrote: > On 12/11/2015 06:42 AM, Chet Ramey wrote: > > On 12/11/15 12:40 AM, Yoriyuki Yamagata wrote: > >> Dear list, > >> > >> I found that bash tries to close the same fd twice, consecutively. I’m > >> using Mac OS X Yosemite, and bash is the newest available (bash-master > >> from http://tiswww.case.edu/php/chet/bash/bashtop.html yesterday). > > > > That's harmless. > > Only if bash is single-threaded (it is) and if no signal handler can > create fds (that, I'm less sure of). It is absolutely harmful in a > multi-threaded program, or in a program where a signal handler might > open an fd and the signal can occur in the window between the two close()s. what about loadable bash plugins ? :) -mike signature.asc Description: Digital signature
Re: My System get vuln in Shellshock, what should i do ?
contact the people who support your distro, or whatever hosting company you might be using -mike signature.asc Description: Digital signature
Re: loadable builtins on HP-UX
On 03 Nov 2015 18:25, Chet Ramey wrote: > On 11/3/15 4:45 PM, Greg Wooledge wrote: > > To the surprise of approximately zero people, loadable builtins don't > > fully work on HP-UX. > > > > I'll spare you any results from 10.20 because it's totally unsupported > > at this point. (It doesn't even use dlopen().) > > > > On HP-UX 11.11, things half work. This is with 4.4-beta, sitting in the > > .../examples/loadables/ directory, after a "make all": > > > > bash-4.4# enable -f ./finfo finfo > > bash: enable: cannot find finfo_struct in shared object ./finfo: Unresolved > > module for symbol: sh_optarg (data) from ./finfo > > > > bash-4.4# enable -f ./tty tty > > bash-4.4# type -a tty > > tty is a shell builtin > > tty is /usr/bin/tty > > bash-4.4# tty > > /usr/lib/dld.sl: Unresolved symbol: reset_internal_getopt (code) from ./tty > > /usr/lib/dld.sl: Unresolved symbol: reset_internal_getopt (code) from ./tty > > ABORT instruction (core dumped) > > It looks like shared objects loaded by dlopen don't have access to the > loading program's symbols. That might be an HP-specific option to dlopen. > It might not, in which case you're out of luck. FWIW, the option on linux is -rdynamic. guess you'll (Greg) want to find the HP-UX equivalent to that. see the configure.ac block for details. -mike signature.asc Description: Digital signature
Re: SIGSTOP and bash's time built-in
On 26 Oct 2015 16:59, Stefan Tauner wrote: > I was creating some exercises for my students when I noticed very > strange behavior of the time built-in when sending SIGSTOP to a timed > command interactively (via ^Z): you could always install the dedicated time program and then do: $ /usr/bin/time sleep 5 that'll handle ^Z and such -mike signature.asc Description: Digital signature
Re: Bug in bash 4.4-beta: suspending and restarting "man" program
what does `stty -a` show on the two systems ? what version of readline are you using on both ? -mike signature.asc Description: Digital signature
Re: updating shopt compat settings to include current version
On 16 Oct 2015 11:37, Chet Ramey wrote: > On 10/15/15 5:30 PM, Mike Frysinger wrote: > >>> the bash compat feature seems to address this nicely: our standard says > >>> we should use bash-3.2, so we set the compat level to that, and then we > >>> have much stronger confidence in newer versions not breaking, or people > >>> adding code that only works on newer versions. > >> > >> You should approach this with caution. I'm sure there are changes and bug > >> fixes that introduce incompatible behavior that are not addressed by the > >> compatNN variables. I guess as long as it doesn't bite you, you're ok. > > > > right. we're OK with reporting & getting those fixed. > > Sometimes they're not going to be `fixed'. Many times those are really > bug fixes or fixes for greater consistency or compatibility. we're not looking for perfect. we understand there's no way to guarantee that (short of keeping around an old version of bash and never upgrading it). the point is to improve the status quo. > >> I mean, in theory, it's simple to do that: > >> > >> unset BASH_COMPAT > >> shopt -u compat31 > >> command shopt -s compat32 2>/dev/null > > > > ... but that doesn't work in bash-3.2: > > $ bash-3.2 -c 'shopt -s compat32' > > bash-3.2: line 0: shopt: compat32: invalid shell option name > > No, it really does. That's why I redirected the output to /dev/null. If > you run with `set -e' enabled, you can follow it with `|| :'. > > Running those commands leaves shell_compatibility_level == 32 on all > existing versions of bash >= bash-3.2. The trick is that on bash-3.2, > unsetting compat31 sets the shell compatibility level to 32, so the > failed attempt to set compat32 doesn't make a difference. my point was to have a code snippet that works for any bash version and a shifting base. we've established that you aren't interested in adding more compat flags, and that BASH_COMPAT is not useful for error checking. fine, we'll just add some ad-hoc checks ourselves using the existing bash version variables. that isn't supposed to sound petulant, just accepting of the reality of the situation. -mike signature.asc Description: Digital signature
Re: updating shopt compat settings to include current version
On 16 Oct 2015 14:26, Chet Ramey wrote: > On 10/16/15 11:37 AM, Chet Ramey wrote: > > unset BASH_COMPAT > > shopt -u compat31 compat32 compat40 compat41 > > shopt -s compat42 2>/dev/null || : > > > > to set shell_compatibility_level to 42 on bash versions >= bash-4.2. > > > > (this needs the attached patch for bash-4.3 to fix a typo in shopt.def) > > And, of course, you can just add > > BASH_COMPAT=42 > > at the end to get around the unpatched bash-4.3 bug. i'm aware of said bug ... Gentoo has included the fix for a long time now -mike signature.asc Description: Digital signature
Re: updating shopt compat settings to include current version
On 15 Oct 2015 16:06, Chet Ramey wrote:
> On 10/15/15 3:27 PM, Mike Frysinger wrote:
> > our build environment relies heavily on bash. in our ebuild standard, we
> > declare the min version of bash that is supported (3.2 currently). this
> > way we don't have people using features found only in newer versions and
> > breaking on systems with older versions of bash.
>
> Wow. How many systems have bash-3.2? It is ten years old, after all. Do
> you build and support new packages for old systems running bash-3.2?
we support it -- if someone reports it. how many reports we actually get
who knows. in practice, it means we disallow newer features like ${foo^^}
and ${foo,,} that are easy to recognize, and we try to write code like
"${PV/_/'~'}" that'll work in both new and old versions.
we're in the process of picking a newer version for the next standard. it'll
be 4.2 or 4.3. but discussion for making upgrades less flaky shook out of the
discussion hence we looked at this compat logic.
> > but when bash changes behavior on us (there are a variety of examples
> > between 3.2 and 4.3), some
> > ebuilds break because they expected bash 3.2 behavior but got something
> > else. so every bash release ends up triggering a fire drill where we try
> > to weed out all the common issues (we have ~20k packages, and many have
> > multiple versions).
>
> Do you ever do any of this work with the alpha and beta versions? It
> seems like there are months there when you could be addressing these
> issues.
yes, when you release alpha/beta versions ;), i add them to Gentoo. but devs
have to explicitly opt into them. i do, and i know one or other people do, but
otherwise i'm not sure how much testing they see.
i've reported at least one such issue already, and i'm pretty sure we've seen
some in the past that got fixed before the final. but the alpha/beta business
is still somewhat new.
> > even then, for a while people introduce bugs since
> > they're running the new version only (or old version), and people notice
> > because things break. then it settles down once everyone has moved to
> > the same version. but i'm sure even today we add code that does not work
> > under bash-3.2 (or some version between then and now), but most people do
> > not notice, and those who do aren't guaranteed to file bugs.
>
> You could always just run bash-3.2 against your ebuild system, or run the
> collection of scripts under bash-3.2, to test whether or not it works.
that assumes that behavior changes only once between versions. pretty sure
we've seen changes where bash-3.2 did one thing, bash-4.3 did something else,
and versions in between did yet another thing. i don't recall exact examples
off the top of my head, but i *feel* like it has happened :).
> > the bash compat feature seems to address this nicely: our standard says
> > we should use bash-3.2, so we set the compat level to that, and then we
> > have much stronger confidence in newer versions not breaking, or people
> > adding code that only works on newer versions.
>
> You should approach this with caution. I'm sure there are changes and bug
> fixes that introduce incompatible behavior that are not addressed by the
> compatNN variables. I guess as long as it doesn't bite you, you're ok.
right. we're OK with reporting & getting those fixed.
> > at any rate, it looks like the intention is to not do what we want, so
> > we'll have to explicitly check the BASH_VERSINFO ourselves up front and
> > deal with the various changes in compat selection.
>
> Is it just the ebuild system or do you want to make sure every shell sets
> compat32?
only the ebuilds. we explicitly do not want external scripts getting screwed
up. that's even more unmanageable :).
> I mean, in theory, it's simple to do that:
>
> unset BASH_COMPAT
> shopt -u compat31
> command shopt -s compat32 2>/dev/null
... but that doesn't work in bash-3.2:
$ bash-3.2 -c 'shopt -s compat32'
bash-3.2: line 0: shopt: compat32: invalid shell option name
and it won't work when we updated to bash-4.2/4.3, or when you stop adding
new compatXY options.
-mike
signature.asc
Description: Digital signature
Re: updating shopt compat settings to include current version
On 15 Oct 2015 14:28, Chet Ramey wrote:
> On 10/15/15 1:34 PM, Mike Frysinger wrote:
> > with bash-4.0, new compat options were introduced:
> > shopt -s compat32
> > and with bash-4.3, a variable was added:
> > export BASH_COMPAT=3.2
> >
> > but things get a little weird when you want to set the compat level to
> > the current version:
>
> Unsetting all the compatNN variables and BASH_COMPAT does this. In fact,
> even if you set, say, compat43, then set and unset BASH_COMPAT, the
> compatibility level is set to the current version (which means that there
> is no compatibility level -- it's an indication of *backwards*
> compatibility, after all).
it's an indication of the standard you want to use. the current standard is
just a different level to be selected.
by this logic, why does BASH_COMPAT accept '4.3' but there is no compat43 ?
seems like your argument is inconsistent.
> > we're interested in this in Gentoo because we want to set the current
> > shell compat level to a min version even if that version is the active
> > one. ideally it'd be:
> > if ! shopt -s compat43 ; then
> > echo "error: >=bash-4.3 required, but ${BASH_VERSION} found" >&2
> > exit 1
> > fi
>
> What practical use does this have? What does Gentoo intend to do with this
> requirement?
our build environment relies heavily on bash. in our ebuild standard, we
declare the min version of bash that is supported (3.2 currently). this
way we don't have people using features found only in newer versions and
breaking on systems with older versions of bash. but when bash changes
behavior on us (there are a variety of examples between 3.2 and 4.3), some
ebuilds break because they expected bash 3.2 behavior but got something
else. so every bash release ends up triggering a fire drill where we try
to weed out all the common issues (we have ~20k packages, and many have
multiple versions). even then, for a while people introduce bugs since
they're running the new version only (or old version), and people notice
because things break. then it settles down once everyone has moved to
the same version. but i'm sure even today we add code that does not work
under bash-3.2 (or some version between then and now), but most people do
not notice, and those who do aren't guaranteed to file bugs.
the bash compat feature seems to address this nicely: our standard says
we should use bash-3.2, so we set the compat level to that, and then we
have much stronger confidence in newer versions not breaking, or people
adding code that only works on newer versions. obviously it's not a
perfect soultion (there isn't really a scalable one), but it's still a
lot better than what we have today.
> > instead we have to probe the active version ourselves:
> > if ! shopt -s compat43 ; then
> > if [[ ${BASH_VERSINFO[0]} -ne "4" || ${BASH_VERSINFO[1]} -ne
> > "3" ]] ; t
> hen
> > echo ...
> > exit 1
> > fi
> > fi
> >
> > the BASH_COMPAT variable isn't as useful:
>
> I disagree. In fact, in a future version I'm going to stop introducing new
> compatNN options in favor of looking at the value of BASH_COMPAT. I really
> don't want to end up with 12 compatNN options.
why not just do it now then and delete all the existing ones ? seems
better to cut people off asap rather than get them used to using it.
> > - possible to accidentally export and impact other shell scripts
>
> It's kind of flip to say, but don't do that.
here's this sharp porcupine. pet it, but not really.
seems like bash should be ignoring BASH_COMPAT when creating a new shell ?
then again, i don't think it does that for other BASH env vars, so probably
don't want to special case it. same as things like POSIXLY_CORRECT.
> > - doesn't fail for
> What?
if you set the variable in older versions, then bash silently accepts it.
shopt is not silent at all.
$ bash-4.3
$ BASH_COMPAT=5.0
bash-4.3: BASH_COMPAT: 5.0: compatibility value out of range
$ bash-3.2
$ BASH_COMPAT=5.0
$ shopt -s compat50
bash-3.2: shopt: compat50: invalid shell option name
at any rate, it looks like the intention is to not do what we want, so we'll
have to explicitly check the BASH_VERSINFO ourselves up front and deal with the
various changes in compat selection.
-mike
signature.asc
Description: Digital signature
updating shopt compat settings to include current version
with bash-4.0, new compat options were introduced:
shopt -s compat32
and with bash-4.3, a variable was added:
export BASH_COMPAT=3.2
but things get a little weird when you want to set the compat level to
the current version:
$ echo $BASH_VERSION
4.3.42(1)-release
$ shopt -s compat43
bash: shopt: compat43: invalid shell option name
$ export BASH_COMPAT=4.3
we're interested in this in Gentoo because we want to set the current
shell compat level to a min version even if that version is the active
one. ideally it'd be:
if ! shopt -s compat43 ; then
echo "error: >=bash-4.3 required, but ${BASH_VERSION} found" >&2
exit 1
fi
instead we have to probe the active version ourselves:
if ! shopt -s compat43 ; then
if [[ ${BASH_VERSINFO[0]} -ne "4" || ${BASH_VERSINFO[1]} -ne
"3" ]] ; then
echo ...
exit 1
fi
fi
the BASH_COMPAT variable isn't as useful:
- possible to accidentally export and impact other shell scripts
- doesn't fail for &1 ) ]] ||
[[ ${BASH_VERSINFO[0]} -lt 4 ]] ||
[[ ${BASH_VERSINFO[0]} -eq 4 && ${BASH_VERSINFO[1]} -lt 3 ]]) ; then
echo ...
exit 1
fi
BASH_COMPAT=4.3
so my request is simple: can we have compatXY added for the current version ?
so in the upcoming bash-4.4 release, get a compat44 option added.
-mike
signature.asc
Description: Digital signature
Re: remaking bash, trying static, glibc refuses static...?
On 18 Aug 2015 21:41, Linda Walsh wrote: > Mike Frysinger wrote: > > On 18 Aug 2015 13:34, Linda Walsh wrote: > > (2) it's using the nss system which lets people drop modules into the system > > at anytime and change the overall lookups to use that. statically linking a > > specific subset would block that ability. > --- > The linux kernel is a perfect example of a statically linked program that > can dynamically load plugins to provide authorization data from external > sources. Static doesn't mean you can't support 3rd party plugins/libs -- > like LDAP. which is what the current glibc code already does and why you get a warning when you link things staticlly. i'm not sure how you can argue both sides of the fence on this. -mike signature.asc Description: Digital signature
Re: quoted compound array assignment deprecated
On 18 Aug 2015 10:51, Chet Ramey wrote:
> On 8/17/15 4:19 AM, isabella parakiss wrote:
> > Quoting is necessary in a few cases:
> >
> > $ var=foo; declare -A "arr$var=([x]=y)"
> > bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
> > $ var=foo; declare -A arr$var=([x]=y)
> > bash: syntax error near unexpected token `('
> > $ var=foo; declare -A "arr$var"=([x]=y)
> > bash: syntax error near unexpected token `('
> >
> > I don't think this should be the default behaiour...
>
> This is exactly the case for which the warning is intended. If you want
> to construct variable names on the fly, use `eval' or don't mix
> declarations of constructed variable names with compound assignment.
>
> You can read the extensive discussion starting at
> http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html.
>
> http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00115.html is the
> newest proposal.
just to double check, the warning from this code is expected ?
$ bash-4.3 -c 'declare -a foo=(a b c); export foo; declare -p foo'
declare -ax foo='([0]="a" [1]="b" [2]="c")'
$ bash-4.4 -c "declare -a foo='(a b c)'"
bash-4.4: warning: foo=(a b c): quoted compound array assignment deprecated
we see this in Gentoo because we save/restore build envs via bash. so all
builds done w/bash-4.3 and older use the quoted syntax, so updating with
bash-4.4 in the system triggers these warnings. we can adjust our tooling
to handle it, but would be nice if older bash didn't do it either. maybe
send out a 4.3-p43 ? ;)
-mike
signature.asc
Description: Digital signature
Re: remaking bash, trying static, glibc refuses static...?
On 18 Aug 2015 13:34, Linda Walsh wrote: > Then can you give any technical reason why a static > lib that uses no network services (i.e. running > on a mini-root ) couldn't be made available for > the various calls that currently claim "dynamic library > support" is necessary. (1) http://www.akkadia.org/drepper/no_static_linking.html (2) it's using the nss system which lets people drop modules into the system at anytime and change the overall lookups to use that. statically linking a specific subset would block that ability. which means people using providers like ldap would be stuck with static binaries that don't work. https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html i'm not going to debate the relevance of such a system nowadays as i don't care. purely pointing out that it's not a "political" issue (nor have you provided any references to back up your specious claim). > Seems simple enough to provide such a widely asked for > feature -- even if it has to be less functional/flexible > than the dynamic version (i.e. Gnu would have done the best > they could under the circumstances). it's already been provided. build glibc w/--enable-static-nss. -mike signature.asc Description: Digital signature
Re: remaking bash, trying static, glibc refuses static...?
it is not political, nor is it related to bash at all -mike signature.asc Description: Digital signature
Re: Feature Request re: syslog and bashhist
On 10 Aug 2015 16:19, Chet Ramey wrote: > On 8/9/15 1:37 PM, aixtools wrote: > > Via google I came across the define named > > > > config-top.h:/* #define SYSLOG_HISTORY */ > > > > Changing it (manually) to > > config-top.h:#define SYSLOG_HISTORY > > > > Adds syslog statements such as: > > Aug 9 16:52:55 x064 user:info syslog: HISTORY: PID=262242 UID=0 ls -ltr > > > > Request #1 > > Add a ./configure variable, e.g., --with-syslog_history > > I will think about this, but I am inclined not to do it. It's easy enough > to enable for those few user who want to do so. we had requests in Gentoo, so the feature is behind a USE flag so people can easily turn it on for their systems. no need to grub around in the source and locate an obscure define. -mike signature.asc Description: Digital signature
Re: general loadable integration
On 16 Jul 2015 14:53, Chet Ramey wrote:
> On 7/14/15 5:11 AM, Mike Frysinger wrote:
> > On 14 Jul 2015 11:35, Pierre Gaston wrote:
> >> I think adoption would be difficult considering even a useful loadable
> >> builtin like "finfo" has not found its way into default installations, b
> ut
> >> for instance I can imagine bash programmable completion could go another
> >> level with an embedded interpreter that lets you access the readline
> >> internals.
> >
> > finfo is under the "examples" directory, and all of the loadable logic is
> n't
> > exactly trivial to package. it feels kind of bolted on, especially when
> you
> > try to build & install things. if we want the loadables to be more of a
> first
> > class concept than something people only play around with locally on thei
> r own
> > systems, this needs polishing.
>
> It's not quite bolted on, but it does assume access to the bash source
> tree, since the header files have to be available. The build tree needs
> to be available as well, since the generated headers are required and
headers can be installed easily. Gentoo does this under the path (arbitrarily
picked) of /usr/include/bash-plugins/. we install a crap ton of headers
because it's not clear what is fair game for plugins.
> the logic to create shared objects comes for free with the bash configure.
that's not really that much magic though ? seems pretty trivial to document
this process ?
> The examples directory is just intended to give developers a flavor of
> how to write a loadable builtin.
perhaps, but i quoted this thread that covers one ("finfo") that was explicitly
called out ...
> The original rationale is that the loadable builtins can be installed
> anywhere, though the example Makefile does not suggest a location, but
> that developers are the ones who need a development environment (the bash
> source tree). Linux vendors could build and include loadable builtins
> as part of their distributions, for example, since they obviously have
> the bash sources.
Gentoo does this as well -- by hand. seems pretty easy to add a rule that'd
install it.
> I suppose the first thing needed to make that work, and maybe the only
> thing needed to make that work, is agreement on the name of a search path
> environment variable that enable can use to find loadable builtins.
Gentoo uses a subdir of the ABI libdir (e.g. /usr/lib64/bash/). but i think
that could easily be a configure time option that'd simply default to
$libdir/bash/.
-mike
signature.asc
Description: Digital signature
Re: gcc fails to build w/bash-4.4_alpha
On 14 Jul 2015 09:17, Chet Ramey wrote: > The following patch removes the code that incorrectly optimizes the fork in > this case. There is a much more direct way to do what I want; that will be > in the next test release. thanks, patch works as advertised ;) -mike signature.asc Description: Digital signature
general loadable integration
On 14 Jul 2015 11:35, Pierre Gaston wrote: > I think adoption would be difficult considering even a useful loadable > builtin like "finfo" has not found its way into default installations, but > for instance I can imagine bash programmable completion could go another > level with an embedded interpreter that lets you access the readline > internals. finfo is under the "examples" directory, and all of the loadable logic isn't exactly trivial to package. it feels kind of bolted on, especially when you try to build & install things. if we want the loadables to be more of a first class concept than something people only play around with locally on their own systems, this needs polishing. -mike signature.asc Description: Digital signature
gcc fails to build w/bash-4.4_alpha
Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I. -I. -I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux vapier 4.0.0 #52 SMP PREEMPT Sun Apr 19 01:10:37 EDT 2015 x86_64 AMD Phenom(tm) II X4 980 Processor AuthenticAMD GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 0 Release Status: alpha Description: no patches applied; just ran: ./configure --with-bash-malloc --enable-mem-scramble make then used the resulting ./bash for tests. since upgrading to bash-4.4-alpha, gcc failed to build on my system. narrowing it down (a bit), it's this command line: /var/tmp/portage/sys-devel/gcc-4.8.5/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.8.5/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -mx32 -O2 -O2 -march=amdfam10 -pipe -g -Wimplicit-function-declaration -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fstack-check=no -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o x32/libgcc_s.so.1.tmp -O2 -march=amdfam10 -pipe -g -Wimplicit-function-declaration -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc \ && rm -f x32/libgcc_s.so \ && if [ -f x32/libgcc_s.so.1 ]; then mv -f x32/libgcc_s.so.1 x32/libgcc_s.so.1.backup; else true; fi \ && mv x32/libgcc_s.so.1.tmp x32/libgcc_s.so.1 \ && ln -s libgcc_s.so.1 x32/libgcc_s.so if i run the same make with SHELL set to bash-4.3, it passes fine. if i rip out that command line and run it in a standalone script w/bash-4.4, it passes fine. running it with set -x shows that it runs the xgcc & rm steps, but that's it. using strace shows xgcc and rm both exit(0), but for some reason bash does not continue to the following commands like it should. if i change the && to a ; after the first rm, it still stops executing at that point. if i change the && to a ; after the xgcc command, then the rest of the commands run fine. attached is the strace. it is not in fork mode, yet the shell clearly does an exec into the rm tool. looks like bash, for some reason, thinks this is the end of the possible commands and so does an optimization to exec into it ? -mike bash-4.4-strace.log.gz Description: Binary data signature.asc Description: Digital signature
Re: Feature proposal/request: input line highlighting
On 11 Jun 2015 18:10, Thomas Wolff wrote: > as opposed to having a fancy colored prompt, I would like to be able to > set up coloring of the whole bash command input line (but not the > following command output). This could be achieved by adding a variable > like "AFTERPROMPT_COMMAND" which is executed after a prompt line is > completed (or "PS9" which is output after a prompt line is completed). > It could even be a nice idea to configure this behavior separately for > bash and readline, so the users have a choice whether to color just > command input, readline-handled program input, or both. > I would appreciate this feature, and maybe even supply a patch if I had > a clue where to hook it in... this is already doable -- leave the end of PS1 enabling color. PS1='\[\e[0;33m\]$ \[\e[34;1m\]' this will color the input buffer blue -mike signature.asc Description: Digital signature
[PATCH] bash(1): ulimit: mention 512-vs-1024 byte sizes with -c/-f in POSIX mode
The change POSIX mode doc discusses these differences, but it would be useful if the ulimit section also contained the minor note about the differences in sizes for the -c/-f flags. Reported-by: Robin Johnson --- doc/bash.1 | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/bash.1 b/doc/bash.1 index 7033a98..3a27f12 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -10166,7 +10166,6 @@ is assumed. Values are in 1024-byte increments, except for which is in seconds; .BR \-p , which is in units of 512-byte blocks; -and .BR \-P , .BR \-T , .BR \-b , @@ -10174,7 +10173,11 @@ and .BR \-n , and .BR \-u , -which are unscaled values. +which are unscaled values; and when in POSIX mode, +.BR \-c +and +.BR \-f +are 512-byte increments instead of 1024-bytes. The return status is 0 unless an invalid option or argument is supplied, or an error occurs while setting a new limit. .RE -- 2.4.1
Re: Check linux 4
On 25 May 2015 17:38, Chet Ramey wrote: > On 5/25/15 9:15 AM, isabella parakiss wrote: > > This is from configure.ac > > > > linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading > > case "`uname -r`" in > > 2.[[456789]]*|3*) AC_DEFINE(PGRP_PIPE) ;; > > esac ;; > > > > It doesn't check for linux 4. > > Two things: > > 1. Is anyone actually using 4.0 in a distribution? all the rolling release distros ? i've been running 4.0 pretty much since it came out. > 2. If you're looking at bash-4.3, why would you have expected a version >from a couple of years ago to check for it? to be fair, that's what the code looks like in git too ... but as long as when 4.4 is released, we don't have the same conversation when linux-5.0 is released ;) > Between configure.ac and BASH_SYS_PGRP_SYNC, I imagine that it will be > covered when 4.0 makes it out to the world. can't we simply delete the uname check ? it's wrong when cross-compiling and redundant with the other macro. -mike signature.asc Description: Digital signature
Re: Check linux 4
On 25 May 2015 15:15, isabella parakiss wrote: > This is from configure.ac > > linux*) LOCAL_LDFLAGS=-rdynamic # allow dynamic loading > case "`uname -r`" in > 2.[[456789]]*|3*) AC_DEFINE(PGRP_PIPE) ;; > esac ;; > > It doesn't check for linux 4. this isn't strictly a problem because there's already the BASH_SYS_PGRP_SYNC macro that does a compile/run test. probably should delete this uname based code entirely at this point ... -mike signature.asc Description: Digital signature
Re: Malicious translation file can cause buffer overflow
On 01 May 2015 01:13, Pádraig Brady wrote:
> On 30/04/15 23:08, Trammell Hudson wrote:
> > Description:
> > The gettext translated messages for "Done", "Done(%d)" and "Exit %d"
> > in jobs.c are copied to a static allocated buffer. A user could set the
> > LANGUAGE variable to point to a malicious translation file that has
> > translations that are longer than 64-bytes for these strings to create
> > a buffer overflow.
> >
> > Since LANGUAGE is passed unchanged by sudo this might be usable for
> > privilege escalation.
> >
> >
> > Repeat-By:
> > Create a .po file with a bogus translation:
> >
> > #: jobs.c:1464 jobs.c:1489
> > msgid "Done"
> > msgstr "Klaar
> > 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
> >
> > And start an interactive shell that puts a command into the background:
> >
> > LANGUAGE="nl.utf8" PS1='$ ' ./bash --noprofile -norc
> > $ sleep 1 &
> > [1] 14464
> > $ sleep 2
> > [1]+ Klaar
> > 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
> >
> > sleep 1
>
> How does one override the system translation?
> I thought gettext only looks in the dir passed to bindtextdomain() ?
but it uses $LANGUAGE in there
$ LANGUAGE=/../../../../../foo/ strace -e file bash --noprofile -norc -c 'echo
$"hi"' |& grep foo
open("/usr/share/locale///../../../../../foo//LC_MESSAGES/im-config.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale///.foo/LC_MESSAGES/im-config.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
open("/usr/share/locale-langpack//../../../../../foo//LC_MESSAGES/im-config.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack//.foo/LC_MESSAGES/im-config.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
-mike
signature.asc
Description: Digital signature
Re: Multiple patches to fix compiler warnings
please post patches inline and as a series rather than attaching a binary tarball. it makes review much harder when you do this. in fact, `git send-email` takes care of all of this for you. -mike signature.asc Description: Digital signature
Re: Usage of __P vs PARAMS in histfile.c
On 08 Apr 2015 14:13, Chet Ramey wrote: > On 4/8/15 11:25 AM, Evan Gates wrote: > > I tried compiling bash with musl-gcc and failed due to the __P macros > > in histfile.c > > > > While digging around it appears that __P is defined in stdc.h, but > > histfile.c indirectly includes rlstdc.h istead. rlstdc.h defines an > > identical macro with the name PARAMS instead of __P > > Yes, you're right. Readline source files need to use PARAMS; bash source > files use __P (history -- don't ask). do you still support such old systems that require this pre-ANSI prototypes ? pretty much all other GNU projects have dropped support for them. -mike signature.asc Description: Digital signature
Re: conflict between gcc and bash malloc lib with static link
On 08 Apr 2015 09:40, Chet Ramey wrote: > I suspect the problem with malloc is that there are one or more additional > symbols in the file (malloc.o) that glibc uses to satisfy some internal > reference, which causes the rest of the symbols from malloc.o to be > loaded, which causes conflicts with the already-loaded bash malloc library. glibc tries pretty hard to avoid symbol conflicts even when static linking. if you're aware of such conflicts, please let us know. there should be no leaking of plain symbols like "foo" or "xmalloc" even w/static libs. -mike signature.asc Description: Digital signature
Re: Experiment to provide a mirror of bash with detailed git history
On 21 Mar 2015 20:19, Chet Ramey wrote: > On 3/16/15 4:54 PM, Eduardo A. Bustamante López wrote: > > I know that some people are interested in a more detailed commit history in > > bash's git repository. After all, it's easier for all of us to just learn to > > use a tool, and use that for everything. > > > > The changelog files distributed with bash are useful, *but*, I claim that > > it'd > > be more useful to use the facilities that git provides for this. Because, it > > already has many useful things, like bisect, blame, log, and so on, that > > only > > work properly if you follow the good practice of making "logical commits". > > I'm interested in how well this turns out. I'm also interested in how > useful you find the changelog entries, since I try to make them very > detailed. i love very detailed changelogs, but their up-front usefulness is curtailed when they can't be clearly attributed to file changes. this is why the idiom of one logical change per git commit works out nicely -- when there's a problem, you've got specific commits & their reasons, and you can use git bisect to help automate tracking down regressions. -mike signature.asc Description: Digital signature
Re: Strange file -i
On 05 Mar 2015 15:20, Chet Ramey wrote: > On 3/4/15 6:07 PM, Stephane Chazelas wrote: > > $ perl -ne 'print if /foo/' * > > I just use grep directly. fwiw, git has a grep helper. this tends to be faster than a plain grep since it automatically filters out ignored files. you just have to remember whether you want to grep source files (things tracked by git) or random generated files (like config.log). -mike signature.asc Description: Digital signature
Re: Strange file -i
On 04 Mar 2015 23:07, Stephane Chazelas wrote: > Note that only GNU utilities (or utilities using GNU getopt > without enforcing standard mode) accept options after arguments. nice that they do too. it's super obnoxious having to manually sort flags. i hate having to use BSD systems w/out GNU userland. -mike signature.asc Description: Digital signature
Re: [PATCH] bracketed paste support
On 30 Oct 2014 18:45, Daniel Colascione wrote: +1 -mike signature.asc Description: Digital signature
change in behavior starting with bash-4.3_p14 and $@ in [[...]]
simple enough code:
foo=(0 0 0); [[ -z ${foo[@]#0} ]]; echo $?
with bash-4.3_p13 and older, this would show 0. starting with bash-4.3_p14,
this now shows 1.
i can't tell from the thread whether this was intentional:
https://lists.gnu.org/archive/html/help-bash/2014-04/msg4.html
-mike
signature.asc
Description: This is a digitally signed message part.
Re: Potential vulnerabilities in BASH 4.3
On Mon 11 Aug 2014 21:07:06 Hádrian R wrote: > Hi, I'm Hádrien Romero Soria - @Kaiwaiata, I am a 16 year old boy, > passionate about computer security, since more than 8h searching and > finding various possible vulnerabilities in source code of bash.. > I will tell you one vulnerability now, if they treat me well I will tell > the other.. > > foolish or important things? > > unsafe use of *strcpy():* > > bash-4.3.tar\bash-4.3\lib\sh\unicode.c: > *line 87: *strcpy (charsetbuf, locale); > > *#* if an attacker manages to take control of *charsetbuf[40];*, may cause > a buffer overflow, which would be directed toward *.bss *it's not too > dangerous but is a vulnerability. depending on the build system, yes, you can trigger a buffer overflow here. all you have to do is set LC_CTYPE to a long string. like so: $ bash -c "LC_CTYPE='$(printf %100sf)' printf '\U8f7f7f20'" bash: warning: setlocale: LC_CTYPE: cannot change locale ( f): No such file or directory *** buffer overflow detected ***: bash terminated === Backtrace: = /lib64/libc.so.6(+0x759fb)[0x7f26630e59fb] /lib64/libc.so.6(__fortify_fail+0x47)[0x7f266316fde7] /lib64/libc.so.6(+0xfdcd0)[0x7f266316dcd0] bash[0x47e3ec] bash[0x46e1bd] bash[0x46eec1] bash[0x41c28e] bash[0x41e454] bash[0x41f526] bash[0x461f24] bash[0x4098c4] bash[0x408786] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f2663090050] bash[0x40947b] === Memory map: 0040-004ae000 r-xp 08:32 1311338 /bin/bash 006ad000-006ae000 r--p 000ad000 08:32 1311338 /bin/bash 006ae000-006b2000 rw-p 000ae000 08:32 1311338 /bin/bash 006b2000-006bc000 rw-p 00:00 0 01e34000-01e55000 rw-p 00:00 0 [heap] 7f2662a8d000-7f2662aa3000 r-xp 08:32 1864333 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/4.9.0/libgcc_s.so.1 7f2662aa3000-7f2662ca2000 ---p 00016000 08:32 1864333 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/4.9.0/libgcc_s.so.1 7f2662ca2000-7f2662ca3000 r--p 00015000 08:32 1864333 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/4.9.0/libgcc_s.so.1 7f2662ca3000-7f2662ca4000 rw-p 00016000 08:32 1864333 /usr/lib/gcc-lib/x86_64-pc-linux-gnu/4.9.0/libgcc_s.so.1 7f2662ca4000-7f266307 r--p 08:32 6705881 /usr/lib64/locale/locale-archive 7f266307-7f2663215000 r-xp 08:32 4459482 /lib64/libc-2.19.so 7f2663215000-7f2663415000 ---p 001a5000 08:32 4459482 /lib64/libc-2.19.so 7f2663415000-7f2663419000 r--p 001a5000 08:32 4459482 /lib64/libc-2.19.so 7f2663419000-7f266341b000 rw-p 001a9000 08:32 4459482 /lib64/libc-2.19.so 7f266341b000-7f266341f000 rw-p 00:00 0 7f266341f000-7f266346e000 r-xp 08:32 4460698 /lib64/libncurses.so.5.9 7f266346e000-7f266366e000 ---p 0004f000 08:32 4460698 /lib64/libncurses.so.5.9 7f266366e000-7f2663672000 r--p 0004f000 08:32 4460698 /lib64/libncurses.so.5.9 7f2663672000-7f2663673000 rw-p 00053000 08:32 4460698 /lib64/libncurses.so.5.9 7f2663673000-7f2663674000 rw-p 00:00 0 7f2663674000-7f266367c000 r-xp 08:32 4458169 /lib64/libhistory.so.6.3 7f266367c000-7f266387c000 ---p 8000 08:32 4458169 /lib64/libhistory.so.6.3 7f266387c000-7f266387d000 r--p 8000 08:32 4458169 /lib64/libhistory.so.6.3 7f266387d000-7f266387e000 rw-p 9000 08:32 4458169 /lib64/libhistory.so.6.3 7f266387e000-7f26638bf000 r-xp 08:32 4458167 /lib64/libreadline.so.6.3 7f26638bf000-7f2663abf000 ---p 00041000 08:32 4458167 /lib64/libreadline.so.6.3 7f2663abf000-7f2663ac1000 r--p 00041000 08:32 4458167 /lib64/libreadline.so.6.3 7f2663ac1000-7f2663ac7000 rw-p 00043000 08:32 4458167 /lib64/libreadline.so.6.3 7f2663ac7000-7f2663ac9000 rw-p 00:00 0 7f2663ac9000-7f2663aeb000 r-xp 08:32 4459479 /lib64/ld-2.19.so 7f2663c72000-7f2663c76000 rw-p 00:00 0 7f2663ce-7f2663ce2000 rw-p 00:00 0 7f2663ce2000-7f2663ce9000 r--s 08:32 6705883 /usr/lib64/gconv/gconv-modules.cache 7f2663ce9000-7f2663cea000 rw-p 00:00 0 7f2663cea000-7f2663ceb000 r--p 00021000 08:32 4459479 /lib64/ld-2.19.so 7f2663ceb000-7f2663cec000 rw-p 00022000 08:32 4459479 /lib64/ld-2.19.so 7f2663cec000-7f2663ced000 rw-p 00:00 0 7fff04d0e000-7fff04d3 rw-p 00:00 0 [stack] 7fff04dff000-7fff04e0 r-xp 00:00 0 [vdso] fff
Re: Tilde expansion during command search
On Wed 23 Jul 2014 08:51:19 Dan Douglas wrote: > On Wednesday, July 23, 2014 09:28:02 AM you wrote: > > On 7/23/14, 8:22 AM, Dan Douglas wrote: > > > Hi, from this discussion: > > > > > > https://github.com/koalaman/shellcheck/issues/195#issuecomment-49678200 > > > > > > I can't find any reference that says substituting a literal tilde in > > > PATH > > > should occur during command search. > > > > Bash has always done this, even back to the pre-version 1 days, and I > > don't > > see any reason to change it now. > > The only concerns I can think of are inconsistency with programs that use > execvp(), or possibly double-expansion in the event of a user name or any > path containing ~. how so ? execvp doesn't do tilde expansion. only the shell does, and it does it once at assignment. -mike signature.asc Description: This is a digitally signed message part.
Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)
On Thu 31 Jul 2014 23:40:18 Linda Walsh wrote: > Chet Ramey wrote: > > type -P echo > > > > ls -l $(type -P echo) > > > > > > If you already have `echo' in the command hash table, type -P will return > > it, since that's what the shell will attempt to execute. > > --- > It's not in the hash table, but type -P still > returns the non-executable. read what Chet said. type -P reflects what the shell will attempt, not what is useful. the fact that it's not usable is irrelevant. if you want to see if it's executable, use `[ -x ... ]`. -mike signature.asc Description: This is a digitally signed message part.
Re: Interactive Expect from bash Script
On Sat 29 Mar 2014 04:26:37 Esben Stien wrote: > Any pointers as to what I can try? if you don't mind me asking, what's with the mixing of languages ? seems like you could accomplish all of this with python alone. are you aware of the pexepct module ? http://pexpect.sourceforge.net/ if you're still set on this amalgamation, then might i suggest looking into the expect-lite package ? http://expect-lite.sourceforge.net/ -mike signature.asc Description: This is a digitally signed message part.
Re: ls doesn't work in if statements in bash 4.3
On Fri 28 Mar 2014 10:23:17 Chris Down wrote: there's really nothing to add to Chris's wonderful post :) -mike signature.asc Description: This is a digitally signed message part.
Re: easier construction of arrays
On Thu 27 Mar 2014 19:15:13 Pierre Gaston wrote:
> On Thu, Mar 27, 2014 at 5:53 PM, Mike Frysinger wrote:
> > On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> > > files=()
> > > while IFS= read -r -d '' file; do
> > >
> > > files+=("$file")
> > >
> > > done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
> >
> > i've seen this construct duplicated so many times :(. i wish we had a
> > native
> >
> > option for it. maybe something like:
> > read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
> >
> > perhaps there is another shell out there that implements something that
> > can replace that loop that bash can crib ?
>
> An option to change the delimiter for readarray/mapfile?
thanks, i wasn't aware of that func. that seems like the easiest solution.
-mike
signature.asc
Description: This is a digitally signed message part.
easier construction of arrays
On Thu 27 Mar 2014 08:01:45 Greg Wooledge wrote:
> files=()
> while IFS= read -r -d '' file; do
> files+=("$file")
> done < <(find . -iname '*.mp3' ! -iname '*abba*' -print0)
i've seen this construct duplicated so many times :(. i wish we had a native
option for it. maybe something like:
read -A files -r -d '' < <(find . -iname '*.mp3' -print0)
perhaps there is another shell out there that implements something that can
replace that loop that bash can crib ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: ls doesn't work in if statements in bash 4.3
On Wed 26 Mar 2014 17:45:33 billyco...@gmail.com wrote: > I thought about the changes I have made recently and I had added the > following into my .bashrc: > > eval $(dircolors -b ~/.dir_colors) > > I commented it out, and now everything works. I think it's still a bug, > though I know how to fix it. doubtful the problem is bash. if ls is writing control codes, then bash will treat them as part of the filename. you can verify by piping the output through hexdump and seeing what shows up. this is a good example though of why using `ls` is almost always the wrong answer. use unadorned globs: for f in dog*; do ... i'd point out that if any of the files in your dir have whitespace, your code would also break: touch 'dog a b c' for f in `ls dog*`; do ... -mike signature.asc Description: This is a digitally signed message part.
Re: Special built-ins not persisting assignments
On Tue 25 Mar 2014 00:39:18 Pollock, Wayne wrote:
> $ echo $BASH_VERSION
> 4.2.45(1)-release
>
> $ unset foo
>
> $ foo=bar :
>
> $ echo $foo
>
>
> $
>
> ===
>
> According to POSIX/SUS issue 7, assignments for special builtins
> should persist. So the output should be ``bar''.
>
> Is there a setting I should turn off (or need to enable), to
> make this work correctly?
>
> I was able to confirm this bug for version 4.2.37(1)-release as
> well. (zsh 4.3.17 (i386-redhat-linux-gnu) has the same bug.)
as noted, this is a feature of bash :)
POSIX also imposes annoying behavior that bash fixes:
unset foo
f() { :; }
foo=bar f
echo $foo
POSIX will show bar (ugh) while bash will not (yeah!)
-mike
signature.asc
Description: This is a digitally signed message part.
Re: When a hashed pathname is deleted, search PATH
On Tue 18 Mar 2014 21:11:07 Linda Walsh wrote: > Mike Frysinger wrote: > > On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > >> Chet Ramey wrote: > >>> Because the execution fails in a child process. You'd be able to fix it > >>> for that process, but would do nothing about the contents of the parent > >>> shell's hash table. > >>> > >>> The way the option works now is to check the hash lookups and delete > >>> anything that is no longer an executable file, then redo the lookup and > >>> hash the new value. > >> > >> > >> Wouldn't bash notice that the child exited in <.1 seconds ( > >> or is it less? > > > > as soon as you talk about trying to time something, you're obviously > > looking at it wrong. having a system that only works when the cpu/disk > > is fast and idle is a waste of time and bad for everyone. > > --- > > Um... this is a User Interface involving humans, and you are looking > for something that needs to be 100%? If this was a reactor control > program, that's one thing, but in deciding what solution to implement to > save some small lookup time or throw it away, an 90% solution is > probably fine. It's called a heuristic. AI machines use them. > Thinking people use them. Why should bash be different? except now you have useless knobs users don't want to deal with, and now your solution is "sometimes it works, sometimes it doesn't, so really you can't rely on it and you have to go back to the same system you've been using all along". trotting out other systems (like defense in depth) doesn't change the fact that your idea is flaky at best and is entirely user visible (unlike defense in depth strategies). i already highlighted a technical way of solving it 100% of the time. -mike signature.asc Description: This is a digitally signed message part.
Re: bash cross with installed readline
On Sun 16 Mar 2014 13:30:55 Andrew Kosteltsev wrote:
> When we build bash for some targets the INCLUDES variable for BUILD_CC
> contains the path to target readline headers. This path points to the
> target headers which not preferred for utilities which prepared for build
> machine.
>
> Also when we have installed readline on the target the configure script
> avoids cross_compilation problems with AC_TRY_RUN and substitutes wrong
> (very old) version of libreadline. If we sure that we installed correct
> readline version we can change configure script for cross compilation
> process.
>
> Please look at attached patches. If this solution can be used for common
> case then please apply these patches for the future versions of bash.
i haven't seen the issues you describe for the first patch. maybe it's
because i don't pass full paths to the target readline but instead let the
toolchain find it for me. so there is never any -I flag mixing.
the 2nd patch is the wrong way to approach the problem. change the AC_TRY_RUN
into an AC_TRY_COMPILE test by relying on RL_VERSION_{MAJOR,MINOR} being
defined and doing an incremental search for its value. see how autoconf
implements its AC_CHECK_SIZEOF macro using only compile tests for the
algorithm.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: When a hashed pathname is deleted, search PATH
On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > Chet Ramey wrote: > > Because the execution fails in a child process. You'd be able to fix it > > for that process, but would do nothing about the contents of the parent > > shell's hash table. > > > > The way the option works now is to check the hash lookups and delete > > anything that is no longer an executable file, then redo the lookup and > > hash the new value. > > > Wouldn't bash notice that the child exited in <.1 seconds ( > or is it less? as soon as you talk about trying to time something, you're obviously looking at it wrong. having a system that only works when the cpu/disk is fast and idle is a waste of time and bad for everyone. if bash could rely on real time signals, sigqueue could be used to send a signal with attached info (like ENOEXEC) and the parent could look for that. alternatively, accept that it's not a real problem in practice for the majority of people as Chet has pointed out ;). -mike signature.asc Description: This is a digitally signed message part.
Re: RFE: a way to echo the arguments with quoting
On Sun 02 Mar 2014 10:12:04 Andreas Schwab wrote: > Dave Yost writes: > > I have an ugly function I wrote for zsh that does this: > > > > Sat 14:17:25 ip2 yost /Users/yost > > 1 634 Z% echo-quoted xyz \$foo 'a b c ' '\n' > > xyz '$foo' 'a b c ' '\n' > > Sat 14:17:53 ip2 yost /Users/yost > > 0 635 Z% > > > > It would be nice if there were an easy way to do this in bash. > > printf "%q" does that. indeed -- also remember that you need "$@" and not $@ (as OP's first e-mail used). e.g.: set -- a 'b c d' 1 2 printf '%q ' "$@" -mike signature.asc Description: This is a digitally signed message part.
Re: pattern substitution expands "~" even in quoted variables
On Fri 07 Mar 2014 16:15:05 Eduardo A. Bustamante López wrote:
> dualbus@debian:~$ for shell in /bin/bash ~/local/bin/bash; do "$shell" -c
> 'p=foo_bar; echo "${p/_/\~} $BASH_VERSION"'; done
> foo\~bar 4.2.37(1)-release
> foo~bar 4.3.0(2)-release
you can get same behavior in <=bash-4.2 and >=bash-4.3 by using single quotes:
P="foo_bar"
MY_P=${P/_/'~'}
echo "${MY_P}"
-mike
signature.asc
Description: This is a digitally signed message part.
Re: Bash-4.3-rc2 available for FTP
On Thursday, January 30, 2014 23:53:55 Andreas Schwab wrote: > Mike Frysinger writes: > > yes, but that's kind of irrelevant for the point raised here. bash's =~ > > uses ERE, and passing in REG_EXTENDED to get ERE semantics with regcomp() > > yields the same result (at least with glibc) as above. > > The effect of \- in an ERE is still undefined. so it is. yet still irrelevant. the GNU library defines behavior explicitly: https://www.gnu.org/software/gnulib/manual/html_node/The-Backslash-Character.html#The-Backslash-Character and it still doesn't explain why every version from bash-3.0 through bash-4.2 behaves the same but bash-4.3 does not. the release notes specifically call out backslash changes to make things "more consistent behavior". i don't changing the behavior of the example i posted makes sense. -mike signature.asc Description: This is a digitally signed message part.
Re: Bash-4.3-rc2 available for FTP
On Thursday, January 30, 2014 23:12:18 Andreas Schwab wrote: > Mike Frysinger writes: > > $ ./a.out 'a\-b' a-b > > regcomp(a\-b) = 0 > > The effect of \- in a BRE is undefined. yes, but that's kind of irrelevant for the point raised here. bash's =~ uses ERE, and passing in REG_EXTENDED to get ERE semantics with regcomp() yields the same result (at least with glibc) as above. -mike signature.asc Description: This is a digitally signed message part.
Re: Bash-4.3-rc2 available for FTP
On Thursday, January 30, 2014 10:48:34 Chet Ramey wrote:
> o. The shell now handles backslashes in regular expression arguments to the
>[[ command's =~ operator slightly differently, resulting in more
>consistent behavior.
hmm, i seem to be running into a bug here. the bash man page suggests that
the behavior should match regex(3), but it doesn't seem to. consider:
$ cat doit.sh
v="a\-b"
[[ ! a-b =~ ${v} ]]
: $?
# This is expected behavior.
$ bash-4.2_p45 -x ./doit.sh
+ v='a\-b'
+ [[ ! a-b =~ a\-b ]]
+ : 1
# This is unexpected behavior.
$ bash-4.3_rc2 -x ./doit.sh
+ v='a\-b'
+ [[ ! a-b =~ a\\-b ]]
+ : 0
compare that to regex(3) behavior:
$ cat test.c
#include
#include
int main(int argc, char *argv[]) {
regex_t preg;
int i1 = regcomp(&preg, argv[1], 0);
int i2 = regexec(&preg, argv[2], 0, NULL, 0);
printf("regcomp(%s) = %i\n"
"regexec(%s) = %i\n", argv[1], i1, argv[2], i2);
return 0;
}
$ gcc test.c
$ ./a.out 'a\-b' a-b
regcomp(a\-b) = 0
regexec(a-b) = 0
it had no problem matching ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: Bash-4.3-rc2 available for FTP
general.c is missing traps.h include: general.c: In function ‘bash_tilde_expand’: general.c:991:3: warning: implicit declaration of function ‘any_signals_trapped’ [-Wimplicit-function-declaration] if (any_signals_trapped () < 0) unicode.c is missing stdio.h include: unicode.c: In function ‘u32tocesc’: unicode.c:141:5: warning: implicit declaration of function ‘sprintf’ [-Wimplicit-function-declaration] l = sprintf (s, "\\u%04X", wc); unicode.c:141:9: warning: incompatible implicit declaration of built-in function ‘sprintf’ [enabled by default] l = sprintf (s, "\\u%04X", wc); expr.c uses a func name that conflicts with glibc's math lib: expr.c:210:17: warning: conflicting types for built-in function ‘exp2’ [enabled by default] static intmax_t exp2 __P((void)); guess it should be renamed to something else. -mike signature.asc Description: This is a digitally signed message part.
Re: Why bash doesn't have bug reporting site?
On Tuesday 14 January 2014 01:31:01 Yuri wrote: > On 01/13/2014 12:32, Eric Blake wrote: > > A mailing list IS a bug reporting system. When something receives as > > low a volume of bug reports as bash, the mailing list archives are > > sufficient for tracking the status of reported bugs. It's not worth the > > hassle of integrating into a larger system if said system won't be used > > often enough to provide more gains than the cost of learning it. In > > particular, I will refuse to use any system that requires a web browser > > in order to submit or modify status of a bug (ie. any GOOD bug tracker > > system needs to still interact with an email front-end). > > e-mail has quite a few vulnerabilities. Spam, impersonation, etc. In the > system relying on e-mail, spam filter has to be present. And due to this > you will get false positives and false negatives, resulting in lost > information. yeah, none of those are real issues, nor are they specific to e-mail. > Among other benefits: > * Ability to search by various criteria. For ex. database-based tracking > system can show all open tickets or all your tickets. How can you do > this in ML? use one of the many archives and do free form text search. or download the files and run `grep` yourself :p. > * Ability to link with patches. In fact, github allows submitters to > attach a patch, and admin can just merge it in with one click, provided > there are no conflicts. git has dirt simple integration with e-mail too. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] bash: add socket server support
On Thursday 14 November 2013 00:50:33 Piotr Grzybowski wrote: > I can think of an attack, just provide me with ip address of the host > :) and a root account password and login :) > > I agree that most systems have other abilities to do the (almost) > same, but yet, all systems (that is to say many more than have nc) > have bash, and while roots on those will expect netcat to be able to > open listen sockets they do not necessarily expect bash to do the > same. > My main point is: this patch means that every user that has access to > who-knows-how restricted shell can open listen sockets, and unless > someone thought of using grsecurity to deny access to bind(2) it is > unrestricted. as Joel said, the functionality he is adding does not impact the attack vector at all. bash already has networking functionality built into it. > This feature should at least be switchable, or otherwise restricted. it already is via a configure flag: --disable-net-redirections -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] bash: add socket server support
On Wednesday 13 November 2013 06:39:45 Irek Szczesniak wrote: > On Wed, Nov 13, 2013 at 7:35 AM, Piotr Grzybowski wrote: > > Hi Everyone, hi Joel, > > > > the idea is nice, and I can really see that it is useful, but I would > > > > be extremely careful with introducing those kind of changes, it can be > > easily interpreted as "backdoor feature", that is: from security point > > of view it could be a disaster. > > ':' in *any* Unix paths is not wise because its already used by $PATH. i don't think that matters here. we aren't talking about any path that is searched via $PATH, we're talking about a bash-internal pseudo path that is checked explicitly. there is no such /dev/tcp/ path on *nix systems; bash keys off that to do internal network parsing. -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] bash: add socket server support
On Thursday 14 November 2013 11:32:18 Cedric Blancher wrote: > On 13 November 2013 15:46, Joel Martin wrote: > > On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak wrote: > >> The other problems I see is: > >> How can the script get access to the data returned by accept()? Unlike > >> ksh93 bash4 has no compound variables yet. > >> How can the accept() socket be passed to a child process so that > >> request processing can be passed to a fork()ed child process? > > > > The accept socket is not exposed to the script by this change. > > Why? > > What happens if someone wishes to set more flags on that socket? does bash even support setting flags on sockets today ? if not, then demanding more than the status quo here is a bit unreasonable. > Or > wishes to have the per-accept() data, like the requester address? Not > all protocols (say, NFS or non-krb5 rsh protocols) embed the request > address in the request itself, and if you look at the Apache archives > it can even be considered an attack of the address from accept() and > in the request do not match (requester spoofing attack). > > So far I can see the server socket you implemented is only barely > enough to do a HTTP server, and not even an good one. it's fsckin bash for fsck sake. it's never going to be able to be a "good" server. it's meant for quick hacks. if you have an important service utilizing this stuff, then your infrastructure deserves to burn to the ground when it fails :P. > Maybe a better way would be to implement something which creates a > server socket for accept, and then have a poll builtin (coincidentally > ksh93v- has a very nice poll(1) implementation) which can be used to > wait both on the accept socket and the sockets returned by accept. If > the accept sockets returns an event you could use something like > /dev/tcpserver/nextaccept to open to obtain the next socket returned > by accept(), and store the accept() data in an env variable. adding other features like this doesn't sound like a bad idea at all, but it also doesn't sound like it should preclude a simple & useful extension to existing bash code. -mike signature.asc Description: This is a digitally signed message part.
Re: bash built-ins `true' and `false' undocumented
On Friday 27 September 2013 16:20:57 Chris Down wrote: > On 2013-09-27 20:19, Roland Winkler wrote: > > Yet I think that the info pages are supposed to provide the definitive > > information about GNU software. So I still believe that it would be > > useful to list these builtins in the info pages, too. Certainly, > > the info pages are more useful for getting an overview. `help foo' > > only helps if you already have some idea of what you are looking for. > > Well, they're directly part of the POSIX spec. I'm not sure there's a > need to reiterate absolutely everything that is already required by > POSIX. on a GNU system, coreutils provides `true` and `false` as well as man & info pages. i don't think having bash duplicate things would be useful in any way. -mike signature.asc Description: This is a digitally signed message part.
Re: `printf -v foo ""` does not set foo=
On Monday 24 June 2013 16:13:01 Chet Ramey wrote:
> On 6/17/13 1:27 AM, Mike Frysinger wrote:
> > simple test code:
> > unset foo
> > printf -v foo ""
> > echo ${foo+set}
> >
> > that does not display "set". seems to have been this way since the
> > feature was added in bash-3.1.
>
> printf returns immediately if the format string is null. It has always
> been implemented this way.
seems like when the -v arg is in use, that [otherwise reasonable] shortcut
should be not taken ?
-mike
signature.asc
Description: This is a digitally signed message part.
`printf -v foo ""` does not set foo=
simple test code:
unset foo
printf -v foo ""
echo ${foo+set}
that does not display "set". seems to have been this way since the feature
was added in bash-3.1.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: currently doable? Indirect notation used w/a hash
On Tuesday 11 June 2013 03:23:29 Chris Down wrote: > On 11 Jun 2013 02:19, "Mike Frysinger" wrote: > > On Monday 10 June 2013 18:20:44 Chris F.A. Johnson wrote: > > > On Mon, 10 Jun 2013, Linda Walsh wrote: > > > >> Point taken, but the only way such a string would be passed as a > > > >> variable name is if it was given as user input -- which would, > > > >> presumably, be sanitized before being used. Programming it > > > >> literally makes as much sense as 'rm -rf /'. > > > > > > > > --- > > > > > > > > That still didn't POSIX-Gnu rm from disabling that ability. > > > > > > Did they? I'm not going to test it :( > > > > do it as non-root: > > $ rm -rf / > > rm: it is dangerous to operate recursively on `/' > > rm: use --no-preserve-root to override this failsafe > > -mike > > If that check didn't exist, rm -rf / would still be dangerous; it would > just give a lot of errors for the files it couldn't delete, and delete the > ones it can. Running it as a normal user doesn't make it safer. sure it does. you just have to be fast :P. -mike signature.asc Description: This is a digitally signed message part.
Re: currently doable? Indirect notation used w/a hash
On Monday 10 June 2013 18:20:44 Chris F.A. Johnson wrote: > On Mon, 10 Jun 2013, Linda Walsh wrote: > >> Point taken, but the only way such a string would be passed as a > >> variable name is if it was given as user input -- which would, > >> presumably, be sanitized before being used. Programming it literally > >> makes as much sense as 'rm -rf /'. > > > > --- > > > > That still didn't POSIX-Gnu rm from disabling that ability. > > Did they? I'm not going to test it :( do it as non-root: $ rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe -mike signature.asc Description: This is a digitally signed message part.
Re: don't just seek to the next line if the script has been edited
On Sunday 09 June 2013 16:59:15 Linda Walsh wrote: > jida...@jidanni.org wrote: > > All I know is there I am in emacs seeing things in the output of a > > running bash script that I want to tweak and get busy tweaking and saving > > changes before the script finishes, thinking that all this stuff will be > > effective on the next run of it, when lo and behold now it begins > > executing random bytes... Yes one can say that these are not C programs > > > If they were C programs, and you were to edit binary in place, while it was > executing, using memory-mapped I/O, the machine might very well start > executing garbage and your C program would dump core or similar. pretty sure the linux kernel (and others?) would return ETXTBSY and not even allow the write -mike signature.asc Description: This is a digitally signed message part.
Re: `declare -fp` mishandles heredoc with || statement
On Saturday 01 June 2013 17:07:33 Chet Ramey wrote:
> On 5/31/13 10:37 PM, Mike Frysinger wrote:
> > simple code snippet:
> > $ cat test.sh
> > func() {
> > cat > / < > 11
> > EOF
> > }
> > declare -fp
> >
> > when run, we see the || statement is incorrectly moved to after the
> > heredoc: $ bash ./test.sh
> > func ()
> > {
> > cat > / < > 11
> > EOF
> > || echo FAIL
> > }
> >
> > every version of bash i tried fails this way (2.05b through 4.2.45)
>
> I don't get this. I see, when using bash-4.2.45:
>
> $ ./bash-4.2-patched/bash ./x1
> func ()
> {
> cat > /tmp/xxx < 11
> EOF
> echo FAIL
> }
>
> I get the same thing going all the way back to bash-4.0. I see the same
> results you do on bash-3.2.51, but that's old enough that it's not going
> to change.
err, yeah, sorry. running too many versions of bash (like 10) made me miss
the subtle nuance of the || being up top vs down below. bash-4.0+ work.
-mike
signature.asc
Description: This is a digitally signed message part.
`declare -fp` mishandles heredoc with || statement
simple code snippet:
$ cat test.sh
func() {
cat > / < / <
signature.asc
Description: This is a digitally signed message part.
Re: Local variables overriding global constants
On Thursday 04 April 2013 10:20:50 Chet Ramey wrote:
> On 4/4/13 12:34 AM, Mike Frysinger wrote:
> >>> would it be possible to enable a mode where you had to explicitly
> >>> `declare +r` the var ? being able to "simply" do `local FOO` allows
> >>> accidental overriding in sub funcs where the writer might not have even
> >>> realized they were clobbering something possibly important.
> >>
> >> It's an idea, but I don't really like the idea of making declare +r,
> >> which is disallowed everywhere else, do something in just this one
> >> special context. Maybe another flag. I'll have to think on it.
> >
> > is there a reason for not just allowing `declare +r` everywhere ? seems
> > like the proposal fits nicely into the existing system (although you've
> > said you're not terribly happy with said system): you can do `declare
> > -gr` to get perm- read only before, or you can do `declare -r` to get
> > read only by default while still allowing sub functions to override if
> > they really want.
>
> The idea, I believe, behind `readonly' is that you want constants. There's
> no reason to even offer the functionality if you can easily make things
> non-constant.
so would the more palpable thing be to introduce a new flag then like -R ?
it'd be like -r, but you could override it in local scope by doing `declare
+R`. e.g. something like:
#!/bin/sh
declare -R VAR=val
foo() {
declare +R VAR=myval
echo $VAR
}
echo $VAR
foo
echo $VAR
this would show:
val
myval
val
but doing something like `local VAR` or `declare VAR` in foo() would result in
an error -- you need the explicit +R.
the issue i'm trying to solve is to provide an environment that protects the
dev from accidental clobbers without preventing the small edge cases when the
dev really truly wants to override something. my proposal above satisfies
that, but i'm not tied to specific details as long as i can support the stated
use case.
-mike
signature.asc
Description: This is a digitally signed message part.
