Hi!
The correct syntax is [ -n ${var} ] (notice the quotes).
Thanks to Vasilis.
A security notice:
Don't use more then one expression in one test call.
Use instant two test calls:
if [ -z $x ] [ -z $y ]; then
echo x and y are empty
fi
if [ -z $x ] || [ -z $y ]; then
echo x or y is
Matthias Maddes Bücher
http://www.maddes.net/
Home: Earth / Germany / Ruhr-Area
On 18.07.2009 21:33, Matthias Buecher / Germany wrote:
Hi everybody,
I just found out that etherwake and busybox's ether-wake are not working
with the default interface eth0, but with br-lan.
This is on a
On Sunday 19 July 2009 13:27:47 Matthias Buecher / Germany wrote:
[...]
I'm done creating the patches for etherwake and busybox's ether-wake to
use br-lan as a default.
But can somebody confirm that br-lan is also a working interface for
other devices or Kamikaze 8.09 in general?
Kamikaze
On Sunday 19 July 2009 14:22:38 Matthias Buecher / Germany wrote:
On 19.07.2009 13:52, Malte S. Stretz wrote:
On Sunday 19 July 2009 13:27:47 Matthias Buecher / Germany wrote:
[...]
And even if eth0 is bridged, etherwake should work on the base device
eth0 as well if I'm not mistaken.
On 19.07.2009 13:52, Malte S. Stretz wrote:
On Sunday 19 July 2009 13:27:47 Matthias Buecher / Germany wrote:
[...]
And even if eth0 is bridged, etherwake should work on the base device eth0 as
well if I'm not mistaken.
Anyway, if it doesn't work for you, I guess the best way to handle this
Hi!
Could you quote an example or deliver an exploit?
A example for the BASH:
if [ -z $do_login -o $user != 'foo' -o $password != 'bar' ]; then
echo login faild
else
echo login success
fi
Normal:
http://[...]/[...]?do_login=1user=foopassword=unknown
Output:
login faild
Exploit:
well I doublechecked it .. and while you are right on the checked input, I am
sure that
if [ -z = ] ...
shouldn't throw an error .. I also tried simple quotes (')
On the other hand, you are right no security issue. Because the right way to
authenticate of course would be..
if [ ! -z
That example is more of an example of unsanitized input and improper error
checking. While it is a common broblem with shell, I don't see how it
relates to the claim made earlier. Is there a better example the doesn't
rely on the user providing unchecked input? Maybe that example would make it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I too still fail to see what's the actual problem. The test utility does
exactly what it's supposed to do.
Of course if you're using a poor method to parse the query string and
then pass the bits unchecked to test it could result in some weird
I too still fail to see what's the actual problem. The test utility does
exactly what it's supposed to do.
in this case
[ -z = ] shouldn't result in ./test.sh: line 6: [: too many arguments
apart from this bug? I still see no problem .. bud
Hello!
well I doublechecked it .. and while you are right on the checked input, I
am sure that
if [ -z = ] ...
shouldn't throw an error .. I also tried simple quotes (')
Yes, only one expression is no Problem in all shell implementations I have
tested.
On the other hand, you are
Alina Friedrichsen wrote:
Hello!
well I doublechecked it .. and while you are right on the checked input, I
am sure that
if [ -z = ] ...
shouldn't throw an error .. I also tried simple quotes (')
Yes, only one expression is no Problem in all shell implementations I have
tested.
Hello!
I too still fail to see what's the actual problem. The test utility does
exactly what it's supposed to do.
Of course if you're using a poor method to parse the query string and
then pass the bits unchecked to test it could result in some weird
side effects.
test is one of the main
Hi!
Thanks for explaining.. this makes perfectly sense and would be right if
the metacharacter hadn't been enclosed in quotes. This should help the
interpreter on its feet again.. shouldn't it?
No the test utility or it's alias [ is designed as a normal external command
like every other
Hi all,
Alina Friedrichsen napsal(a):
Hi!
The correct syntax is [ -n ${var} ] (notice the quotes).
Thanks to Vasilis.
A security notice:
It can become a security issue when any function is wrongly used in a security
context.
I would mark this one only as a general warning.
Don't use
Hi all,
A common workaround for this is to use
[ x$var == x ] instead of [ -z $var ]
and
[ x$var != x ] instead of [ -n $var ]
which doesn't exhibit the mentioned problem.
Regards,
Aleksandar
Alina Friedrichsen wrote:
Hi!
Thanks for explaining.. this makes perfectly sense and would
16 matches
Mail list logo
