. (source) builtin behavior changed when commands are in {} braces
In previous version (3.0) bash continue after {} braces.
For example:
{
readonly a
a=10
} || :
echo hello
In bash 3.2 we've got error message about readonly variable, but "hello"
is not printed. Is this right behavior or bug?
I investigate this problem and found, that there is added
top_level_cleanup () function. I don't know what is going on in this
function, but probably is changing top_level (saved stack context) and
further calling jump_to_top_level () jumps elsewhere then in bash 3.0.
For now I comment out calling top_level_cleanup(), but I know, that
there is better way.
begin:vcard
fn:Roman Rakus
n:Rakus;Roman
org:Red Hat;BaseOS
adr:;;;Brno;;;Czech Republic
email;internet:[EMAIL PROTECTED]
title:Associate software engineer
tel;cell:+420 774 891 861
x-mozilla-html:FALSE
version:2.1
end:vcard
Re: . (source) builtin behavior changed when commands are in {} braces
Roman Rakus wrote:
In previous version (3.0) bash continue after {} braces.
For example:
{
readonly a
a=10
} || :
echo hello
In bash 3.2 we've got error message about readonly variable, but "hello"
is not printed. Is this right behavior or bug?
I'm not sure what changes you've made to the red hat version of bash, but
bash-3.2.17 and bash-3.2.39 (the two versions I happen to have on this
machine) both print `hello' after the error message. The top_level_cleanup
function and the calls to it were introduced in bash-3.2 patch 20, so
the behavior appears to be consistent before and after the patch.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
CDPATH reports to stdout and even non-interactively
Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2 -L/usr/src/packages/BUILD/bash-3.2/../readline-5.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -pipe -g -fPIE -fprofile-use uname output: Linux bow 2.6.22.13-0.3-default #1 SMP 2007/11/19 15:02:58 UTC i686 i686 i386 GNU/Linux Machine Type: i586-suse-linux-gnu Bash Version: 3.2 Patch Level: 25 Release Status: release Description: If CDPATH is set, whenever bash changes directories to a non-absolute path it reports the new directory to stdout. This is done even if bash is running in non-interactive mode, such as in a script. That breaks scripts that do things like this: (cd /foo/bar; do-something; cd foo; echo Important information) > bar or, more commmonly, ones that do this: cd /foo/bar; do-something; cd foo; echo Important information when their output is redirected. Repeat-By: export CDPATH=.:.. cd / (cd etc) > /tmp/bashcdpath cat /tmp/bashcdpath # /etc is shown cat > /tmp/bashcdpathbug << EOF #!/bin/bash cd /etc echo This should be the only output cd tmp EOF chmod +x /tmp/bashcdpathbug /tmp/bashcdpathbug > /tmp/bashcdpath2 wc -l /tmp/bashcdpath2 # File contains two lines when it should have only one rm -f /tmp/bashcdpath* Fix: Bash should only report CDPATH status in interactive mode. Furthermore, CDPATH status (like all such human-interest information) should be reported to stderr, not stdout. I would also argue that CDPATH should only be respected in interactive mode. Otherwise, there's a potential security hole with respect to scripts that use relative directory changes (and potential bugs in other scripts, which is how this problem as discovered).
Perhaps more than CDPATH is risky
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2
-L/usr/src/packages/BUILD/bash-3.2/../readline-5.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-suse-linux-gnu'
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586 -mtune=i686
-fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -D_GNU_SOURCE
-DRECYCLES_PIDS -Wall -pipe -g -fPIE -fprofile-use
uname output: Linux bow 2.6.22.13-0.3-default #1 SMP 2007/11/19 15:02:58 UTC
i686 i686 i386 GNU/Linux
Machine Type: i586-suse-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
With respect to my previous report on CDPATH, Werner Fink of
SuSE (now Novell) has some additional comments:
Maybe there are some more variables which are normaly used in
interactive mode but also available in script mode. The question
rises how many scripts are out there relying on such variables
like CDPATH and others:
#!/bin/bash
CDPATH=/tmp
tmp=$(mktemp -d ${CDPATH}/${0##*/}.XX) || exit 1
wrk=${tmp##*/}
cd $wrk
Repeat-By:
I think somebody needs to audit bash to ask the following questions:
(1) If environment variable X is imported to a script, what
are the bad effects?
(2) What is the probability that a script writer will remember
to reset X? (Heck, how many scripts even reset IFS? And
that's been well known about sh for 20 years.)
(3) If X is disabled in non-interactive mode, what are the bad
results?
(4) Is it sufficient to null out X on startup, and then let
the script reset it if it chooses?
Without doing the audit, I'd guess that the answer to #4 is
nearly always (or, more likely, always) yes.
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
Re: \w in PS1 hopelessly confuses bash in workdir ending in \
Hi *, Am 2008-08-06 17:08:12, schrieb Chet Ramey: > > which seems harmless enough. However, if you do > > > > mkdir /tmp/chaos\\ ; cd /tmp/chaos\\ > > > > the prompt display hopelessly confuses bash. At first it displays > > nothing at all, then with repeated entries of RET fragments of color > > ANSI sequences appear, like > > > > [EMAIL PROTECTED]:/tmp/xxx$ mkdir /tmp/chaos\\ ; cd /tmp/chaos\\ > > ]0;[EMAIL PROTECTED]: /tmp/[EMAIL PROTECTED]:/tmp/chaos\$ > > ]0;[EMAIL PROTECTED]: /tmp/[EMAIL PROTECTED]:/tmp/chaos\$ > > Since bash doesn't output any of that by default, I suspect you have something > in PROMPT_COMMAND that tries to write to an xterm title bar and is confused by > the escape at the end of the prompt string. I tested it with export PS1='[\h:\w\] ' and export PS1='\[ESC[1;[EMAIL PROTECTED]:ESC[36m\wESC[33m]ESC[0m ' abd both I get: [EMAIL PROTECTED]:~] cd /tmp [EMAIL PROTECTED]:~] mkdir /tmp/chaos\\ ; cd /tmp/chaos\\ [EMAIL PROTECTED]:/tmp/chaos\] It seems to be an non-escaped coloring sequence Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: CDPATH reports to stdout and even non-interactively
[EMAIL PROTECTED] wrote: Bash Version: 3.2 Patch Level: 25 Release Status: release Description: If CDPATH is set, whenever bash changes directories to a non-absolute path it reports the new directory to stdout. This is done even if bash is running in non-interactive mode, such as in a script. That breaks scripts that do things like this: This is the behavior that Posix requires: when CDPATH is used, bash outputs the name of the new working directory to stdout. Commands and shell functions need to take this into account. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: Perhaps more than CDPATH is risky
[EMAIL PROTECTED] wrote: I think somebody needs to audit bash to ask the following questions: (1) If environment variable X is imported to a script, what are the bad effects? (2) What is the probability that a script writer will remember to reset X? (Heck, how many scripts even reset IFS? And that's been well known about sh for 20 years.) (3) If X is disabled in non-interactive mode, what are the bad results? (4) Is it sufficient to null out X on startup, and then let the script reset it if it chooses? The man page and info doc should list all of the shell variables that affect bash's behavior. If that's not the case, please report it. As for IFS, the shell does reset it to " \t\n" at startup (which I cribbed from the Korn shell). That's why bash scripts don't reset it themselves. If by (4) you mean that the shell should ignore variables from the environment when it starts up in non-interactive mode, there will have to be a very good case made to introduce this level of backwards incompatibility. That case hasn't been made yet. (And the CDPATH issue has come up before. Several times.) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: CDPATH reports to stdout and even non-interactively
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Chet Ramey on 8/15/2008 3:14 PM: > > This is the behavior that Posix requires: when CDPATH is used, bash > outputs the name of the new working directory to stdout. Commands > and shell functions need to take this into account. And in general, it is a bad idea to export CDPATH. Using it in interactive shells as a non-environment shell variable is fine, but exporting it affects non-interactive shells. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkimFosACgkQ84KuGfSFAYBGggCfWc0IKnIYSuul73ZaNsa6S5Rl hSwAn01Si7Fi+Z4UEOGbUedG411Jk8wL =jg2N -END PGP SIGNATURE-
Re: CDPATH reports to stdout and even non-interactively
> And in general, it is a bad idea to export CDPATH. Using it in > interactive shells as a non-environment shell variable is fine, but > exporting it affects non-interactive shells. There are good reasons to export CDPATH. In particular, CDPATH is inherited by interactive subshells. For precisely that reason, my startup files are careful to avoid resetting CDPATH, so that if I want to change it and then invoke an interactive subshell I won't have to change it a second time. In general, it's a bad idea to assume that one's own usage patterns match those of all other users. -- Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/ The P in "PDF" is a lie.
Re: CDPATH reports to stdout and even non-interactively
>> Description: >> If CDPATH is set, whenever bash changes directories to a >> non-absolute path it reports the new directory to stdout. >> This is done even if bash is running in non-interactive mode, >> such as in a script. That breaks scripts that do things like >> this: > > This is the behavior that Posix requires: when CDPATH is used, bash > outputs the name of the new working directory to stdout. Commands > and shell functions need to take this into account. Actually, the Posix standard is ambiguous. Although it (foolishly) requires reporting to stdout rather than stderr, it does not mention whether this behavior is required for both interactive and non-interactive shells. When the Posix standard is ambiguous or just plain wrong, it's better to work to change or clarify it than to guess and to slavishly follow it. In the current case, it's clearly incorrect to report the new working directory, which is intended as feedback to humans, to stdout. So the Posix standard should be changed in the next revision. > The man page and info doc should list all of the shell variables that > affect bash's behavior. If that's not the case, please report it. In other words, "If a sneaky security hole is documented by implication in the 5000-line man page, there is no need to close the hole." A better approach is to take an attitude of "To the extent possible, shell script writers should be able to write secure scripts without worrying about obscure interactions between their script and the invoking environment." > As for IFS, the shell does reset it to " \t\n" at startup (which I > cribbed from the Korn shell). That's why bash scripts don't reset > it themselves. See the above. Dave Korn added that feature because of all the security holes introduced by IFS, which definitely falls into the "obscure interactions". We're smarter about that sort of stuff now than when Steve Bourne wrote the original sh; we should be trying to minimize that kind of thing rather than maximize it. > If by (4) you mean that the shell should ignore variables from the > environment when it starts up in non-interactive mode, there will have > to be a very good case made to introduce this level of backwards > incompatibility. That case hasn't been made yet. I don't mean that the shell should ignore ALL environment variables; that would break a ton of scripts. Even ignoring PATH would be a Very Bad Thing, since we've long ago grown used to inheriting PATH. What I meant was that we should audit the inherited variables, and make an intelligent and informed decision about each on a case-by-case basis. See below for suggestions. > (And the CDPATH issue has come up before. Several times.) That's a sign that there's a real problem here. Here's an analysis of all the document environment variables. I'll only mention variables that might be risky from a security standpoint BASH_ENVis the cracker's delight. Any setuid program that invokes a Bash script, even indirectly, is completely open to attack. I can't see any way to make this feature safe, although it would certainly help to deny it if the UID is zero (but there are sensitive non-root accounts that could still be attacked). It's worth noting that BASH_ENV has been used in cracks in the past. CDPATH Should be unset in non-interactive mode. Scripts are unlikely to want to inherit CDPATH; if they want to use it they can easily set it themselves. GLOBIGNORE Should be unset in non-interactive mode. I can't come up with a crack in 10 seconds, but I'm confident that within 30 minutes I could figure out a way to abuse a script by controlling its globbing. HOMEMight be abusable, but as with PATH, scripts generally assume it's untrusted. IFS Already being reset IGNOREEOF Already ignored in non-interactive shells (and another example of where we had to learn the hard way). MAILShould be ignored in non-interactive mode (and probably already is). OPTERR It's worth noting that bash gets this one right. In other words, there's precedent for handling other variables correctly. PATHWell known, so OK. POSIXLY_CORRECT I'm not sure about the security implications of this one, because I don't know everything it changes. Superficially, it seems OK, but somebody more knowledgeable about all its effects should spend some time thinking about how to crack a script by manipulating it. TMPDIR This one is pretty well known. It's abusable, but removing it would be pretty bad for backw
Re: CDPATH reports to stdout and even non-interactively
Geoff Kuenning wrote: I don't mean that the shell should ignore ALL environment variables; that would break a ton of scripts. Even ignoring PATH would be a Very Bad Thing, since we've long ago grown used to inheriting PATH. Ignoring PATH would make life much, MUCH harder. I just finished writing a script that relies on PATH being set a particular way; in fact, I even check that it is and refuse to run otherwise. (Ok, I guess I could set the path myself, but it's for a development environment, and making the user do it means less chance for them to shoot themselves in the foot later because PATH is set wrong. Oh, and if ALL environment variables were ignored, I wouldn't even be able to fix PATH, because I need a different environment variable to know where the source tarball got unpacked... or else, the script would have to instead make assumptions about the current directory. So, ah, yeah, ignoring PATH would IMO be bad, ignoring /everything/ would cause me to find another shell that's less fatally brain-dead ;-).) And I know I have umpteen scripts floating around that are intended to run in a particular environment and will break otherwise. So... yeah, let's not go there ;-). (I wouldn't be surprised if CDPATH is the same way, to be honest, i.e. I wouldn't be surprised if there are scripts that require it to be set a particular way.) BASH_ENV Hmm, I know I rely on that, but maybe for starting new bash instances (i.e. set from script and rely on the new shell to inherit it). But I guess that's sort-of the whole point of the variable in the first place, so... HOME Again, if bash were to start ignoring HOME, I'm fairly sure that would break a bunch of my scripts. (Yeah. I have a particular environment in which I abuse HOME, setting it to something other than my home directory, but...) PATH See above ;-), but I guess you were already convinced that mucking with this would be a problem, so that's good :-). -- Matthew In the beginning, there were not enough colors. -- Guy Keren
Re: CDPATH reports to stdout and even non-interactively
Geoff Kuenning <[EMAIL PROTECTED]> wrote: > BASH_ENVis the cracker's delight. Any setuid program that > invokes a Bash script, even indirectly, is completely > open to attack. Nope. Look at the -p option for set. BASH_ENV can be used to cause scripts to go haywire, but only with your own account. > CDPATH Should be unset in non-interactive mode. Scripts are > unlikely to want to inherit CDPATH; if they want to > use it they can easily set it themselves. Not necessarily. In some cases, it may be that a script relies on the inherited CDPATH as a way for the user to tell it where to operate - that is, a script might treat it just like HOME, PATH, and TMPDIR. In cases like that, the script can't know what value the user wants CDPATH to be set to. (Though it's still true that many other scripts don't treat it that way and may be vulnerable to abuse.) CDPATH and GLOBIGNORE could at least be added to the -p handling, I'd say. The trouble with unsetting an inherited variable in non-interactive shells is that it screws up the situation where an interactive shell invokes a non-interactive shell, which then invokes another interactive shell. The second interactive shell should get the same environment that the first one had, but it won't if the non-interactive one in between makes changes for its own benefit. So a non-interactive shell could simply ignore the inherited value without modifying the environment that it passes on to subprocesses, but that carries surprises of its own. > MAILShould be ignored in non-interactive mode (and > probably already is). Right. (Likewise for MAILPATH.) Mail checking happens before displaying the primary prompt, which non-interactive shells don't do. paul
Re: CDPATH reports to stdout and even non-interactively
Geoff Kuenning wrote: Actually, the Posix standard is ambiguous. Although it (foolishly) requires reporting to stdout rather than stderr, it does not mention whether this behavior is required for both interactive and non-interactive shells. It's not, really. Unless otherwise specified (and the standard is pretty good about saying "interactive shell" when it means an interactive shell), the specified behavior applies to all shell invocations. You might not agree with it, but it's not ambiguous. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
