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 s
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 m
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 co
Alina Friedrichsen wrote:>
> The test function can't know what do you mean if you have more then one
> expression.
>
> With
> [ -n = -a #[...]
> you can mean that:
>
> 1. if the string "=" is non empty and something other is true
> or
> 2. if the string "-n" is equal to the string "-a"
>
> the
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 th
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 h
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
> 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
__
-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
Hi!
> 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
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 "$do_
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
clea
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=1&user=foo&password=unknown
Output:
login faild
Explo
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
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 handl
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
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
Could you quote an example or deliver an exploit?
thanks bud
> 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"
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
ech
19 matches
Mail list logo
