Re: cd with multiple arguments?
Le 16/12/2010 01:45, Bob Proulx a écrit : > The shell isn't the only one that introduces a security vulnerability > on most systems when setuid. All interpreters are the same in that > regard. On systems where you shouldn't suid scripts then you > shouldn't suid any of the set of sh/perl/python/ruby scripts either. > I think most people would consider at least one of those in that set a > real programming language. :-) None of these other languages has the same quoting complexity. You can find some FAQs saying: "Never setuid a shell script, use something less dangerous instead like Perl for instance". I imagine it is too difficult to appreciate this complexity and objectively compare it to other languages when you are an expert in it.
Re: cd with multiple arguments?
Marc Herbert wrote: > Bob Proulx a écrit : > > The shell isn't the only one that introduces a security vulnerability > > on most systems when setuid. All interpreters are the same in that > > regard. On systems where you shouldn't suid scripts then you > > shouldn't suid any of the set of sh/perl/python/ruby scripts either. > > I think most people would consider at least one of those in that set a > > real programming language. :-) > > None of these other languages has the same quoting complexity. You can > find some FAQs saying: "Never setuid a shell script, use something > less dangerous instead like Perl for instance". I didn't say anything about quoting. The topic here was security vulnerabilities of an suid script. For example the classic race condition between stat'ing the #! interpreter and launching the privileged process on the file. If the system has that behavior then any #! interpreter (including non-interpreters such as 'ls') are vulnerable to an attack of slipping a different interpreter in at the last moment. That has nothing to do with quoting and is not specific to any particular interpreter. All that is required is that it not be directly machine executable binary code such that exec(2) can't invoke it directly but must instead invoke the specified program upon it. If an FAQ reports that using Perl is okay to be setuid in that environment then I think it is wrong. Or at least not completely general and portable because it is certainly dangerous on Unix systems. But it has been so many years since I have looked at that problem that I don't remember the details. I do remember using the exploit on HP-UX systems years ago but I don't remember the specific behavior here of all of the different kernels in popular use. Please don't make me expend precious brain cells remembering it. Bob
nounset option does not work with array in arithmentic expressions
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -
DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -
DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -
DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux CL3MMH29 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24
09:00:03 UTC 2010 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.1
Patch Level: 5
Release Status: release
Description:
I want to use the nounset option and I found that the option does not work
with array-values in
a arithmethic expression. See the following example:
jo...@cl3mmh29:~$ set -o nounset
jo...@cl3mmh29:~$ declare -ai ar
jo...@cl3mmh29:~$ ar[0]=1
jo...@cl3mmh29:~$ let y=ar[1]
jo...@cl3mmh29:~$ echo $y
0
The value of variable ar[1] is expanded to 0 although it was not set.
The full syntax produces the expected behavior:
jo...@cl3mmh29:~$ let z=${ar[1]}
bash: ar[1] ist nicht gesetzt.
Repeat-By:
permanent
Fix:
The full syntax produces the expected behavior:
jo...@cl3mmh29:~$ let z=${ar[1]}
bash: ar[1] ist nicht gesetzt.
