Thursday, June 18, 2009
Some Interesting Google Tricks
Hey there,
I got a little involved in making Visio diagrams today and lost track of time (In just under 8 hours I managed to produce a crude depiction of a full rack in a datacenter). And thank goodness I had the software to help me out. I never would have been able to legitimately waste that much time in a row on my own ;)
So today, I found this video on a site called FunnyHack. The video below is from there and doesn't contain anything below-board that I noticed... It's funny how the opposite of above-board just doesn't sound quite right. The same with the opposite of upper-handed ;)
Enjoy the video and check the site out . A lot of it is Windows-related, but there are quite a few entries over there that appeal to the general public (like how to hack an elevator :)
Cheers,
[埋込みオブジェクト:http://www.metacafe.com/fplayer/735401/google_tips_and_tricks.swf]
Google Tips And Tricks - These bloopers are hilarious
, Mike
Please note that this blog accepts comments via email only . See our Mission And Policy Statement for further details.
Monday, May 26, 2008
How To Fake Associative Arrays In Bash
Greetings,
As promised in our previous post on working with associative arrays in Linux and Unix, we're back to tackle the subject of associative arrays in bash. As was noted, we're using bash version 2.05b.0(1) and (to my knowledge) bash ( up to, and including, bash 3.2 ) does not directly support associative arrays yet. You can, of course, create one-dimensional (or simple index) arrays, but hashing key/value pairs is still not quite there.
Today we'll check out how to emulate that same functionality in bash that can be found in Perl and Awk. First we'll initialize our array, even though we don't necessarily have to:
host # typeset -a MySimpleHash
To begin with, we'll have to consider what bash already does for us and how we want that to change. For our first example, let's take a look at what happens if we just make assignments to a bash array with, first, a numeric and then an alpha value:
host # MySimpleHash["bob"]=15
host # echo ${MySimpleHash["bob"]}
15
host # MySimpleHash["joe"]="jeff"
host # echo ${MySimpleHash["joe"]}
jeff
This seems to be working out okay, but if we look at the values again, it seems that MySimpleHash["bob"] gets reassigned after we assign the alpha value "jeff"to the key "joe" :
host # echo ${MySimpleHash["bob"]}
jeff
This behaviour repeats itself no matter if we mix integers with strings. Bash can't handle this natively (but, it never claimed it could :)
host # MySimpleHash["bob"]="john"
host # echo ${MySimpleHash["bob"]}
john
host # MySimpleHash["joe"]="jeff"
host # echo ${MySimpleHash["joe"]}
jeff
host # echo ${MySimpleHash["bob"]}
jeff
This looks as though it's going to necesitate an "eval" nightmare much much worse than faking arrays in the Bourne Shell! Ouch! However, we might be able to get around it with a little bit of "laziness" if we just construct two parallel arrays. This, of course, would necessitate keeping the values in both arrays equal and consistent. That is, if "bob" is the third key in our associative array, and "joe" is "bob"'s value, both need to be at the exact same numeric index in each regular array. Otherwise translation becomes not-impossible, but probably a real headache ;)
To demonstrate we'll create a simple "3 key/value pair" associative array using the double-regular-array method, like so:
host # typeset -a MySimpleKeys
host # typeset -a MySimpleVals
host # MySimpleKeys[0]="abc";MySimpleKeys[1]="ghi";MySimpleKeys[2]="mno"
host # MySimpleVals[0]="def";MySimpleVals[1]="jkl";MySimpleVals[2]="pqr"
Now, we should be able to "fake" associative array behaviour by calling the common index from each array (In this fake associative array we have key/value pairs of abc/def, ghi/jkl and mno/pqr). Now that we have the key/value pairs set up, we need to set up the "associative array" so that we can request the values by the key names, rather than the numeric array index. We'll do this in a script later, so our command line doesn't get any uglier:host # key=1ドル
host #for (( x=0 ; x < ${#MySimpleKeys[@]}; x++ ))
>do
> if [ $key == "${MySimpleKeys[$x]}" ]
> then
> echo "${MySimpleVals[$x]}"
> fi
>done
Testing this on the command line produces suitable, but pretty lame looking results:
host # ./MySimpleHash ghi
jkl
We're going to need to modify the script so that it takes its keys and just returns a value that doesn't need to be cropped (using "echo -n" will solve this nicely):
echo "${MySimpleVals[$x]}"
changes to
echo -n "${MySimpleVals[$x]}" <--- This is helpful if we want to use the result as a return value :)
Still, the shell is going to balk at whatever we do to try and pass an argument to the script like this:
host # ./MySimpleHash{ghi}
-bash: ./MySimpleHash{ghi}: No such file or directory
So, for now, we'll just make it so it's "almost" nice looking:
host # a=`./MySimpleHash {abc}`
host # echo $a
def
It'll get the job done, and could be used in a pinch, but is way too klunky to replace Awk or Perl's built-in associative array handling. Nevertheless, at least we have a way we can get around it if we "have" to :)
I've included the script written during this post below, but, if you want to check out a more complex (and, subsequently, much more elegant) script to fake associative arrays in Perl, you should take a look at this associative array hack for bash and also this bash hack that comes at the issue from a whole different angle.
I think you'll like either one of these scripts a lot better than this one, but hopefully we've both learned, at least a little bit, about the way associative arrays work (and how they differ from one dimensional arrays) in the process :)
Cheers,
Creative Commons License
This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License #!/bin/bash
# TerribleAAbashHack.sh
# What was I thinking?
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#
typeset -a MySimpleKeys
typeset -a MySimpleVals
MySimpleKeys[0]="abc";MySimpleKeys[1]="ghi";MySimpleKeys[2]="mno"
MySimpleVals[0]="def";MySimpleVals[1]="jkl";MySimpleVals[2]="pqr"
key=`echo $@|sed -e 's/{//g' -e 's/}//g'`
for (( x=0 ; x < ${#MySimpleKeys[@]}; x++ ))
do
if [ $key == "${MySimpleKeys[$x]}" ]
then
echo -n "${MySimpleVals[$x]}"
fi
done
, Mike
Sunday, March 9, 2008
Paying Attention To The Small Things.
Hey There,
Computer security, for Linux and Unix, grew into its own industry probably decades ago, now. It's my own opinion, after working in this arena for around 12 years or so (or is it 11? Time to check my pulse ;) that a lot of time is wasted in middle-corporate America worrying about Sarbanes Oxley and whatever security fad replaces it. I'm not arguing that there shouldn't be high standards for company's who's job it is to "secure" things; like our credit card numbers, social security information and what have you. But, then, most of those folks aren't shooting for Soxley certification; they've already got it and that may make your information safer... probably.
Most places I've passed through, or stayed at for an extended length of time, were generally "in the process" of becoming certified in "this," which was soon to be replaced by "that" certification. And God bless everyone who makes a living trying to keep our stuff as secure as possible. They provide a valuable service and should be respected, even if they do insist that we follow the rules ;)
A lot of times, in this continuous shifting of security paradigms, the little things get overlooked. Thousands of servers will get patched over the course of a year, while accounts with simple passwords (belonging to disgruntled employees who stormed off the job years ago) sit around on, sometimes, publicly accessible boxes. And there's really not too much we can do about it (aside from getting more systems administrators and Unix/Linux professionals on the payroll :) except continue to do what we can to try and keep things sane. There will always be a weakest link in any given system and, for every link, some malcontent looking to "break a link" to let off a little steam ;)
To demonstrate what I mean about the tenuousness of the security we all think we enjoy, I present the following line of code that anyone with sufficient permission (or on a machine that isn't locked down so tightly that it's barely usable) can execute. Of course, the old trick is to get someone else to execute it for you...
(ls -R / &);exec ls
Yes, that's it. That or any other command that's accessible to most users. If you put that line in an executable file called:
ls <--- Or whatever the name of the command you're calling from within your script is.
you can run up some numbers really quick. I realize this is a lame trick, but it's pretty much my policy that I don't put anything out on this blog that's seriously detrimental. Anyone who can program shell or Perl and understands the concepts of forking, exec'ing and/or infinite recursion can come up with a million ways to exploit this weakness. Sometimes it happens by accident, like when they first introduced frames in HTML (Remember that?) Whoops ;)
And here's to the gentleman/lady who, some time in the future, figures out how to make it impossible for people to do this sort of thing while leaving a system usable. As far as I know, at this point, the only protection against attacks from the inside like these is removing all user accounts, including root... and then pulling the plug and dropping a refrigerator on your server; assuming your server isn't the size of a refrigerator. In any event, if you decimate the entire city block your server resides on, that should take care of the issue ;)
I generally have faith in people, and treat them as untrustworthy only after they've shown me that they can't be trusted. I find it hard to have respect for cut-and-paste "script kiddies" who go out and wreak havoc on systems or corporations with little or no understanding of the mechanisms that underlie their reckless behaviour. I do believe that we need to keep paying people to ethically hack our systems regularly. I remember when this was standard practice (perhaps it still is, somewhere in the world I haven't work in a while ;) and it always seemed like a good idea to me. In the worst case, you were allowing someone to channel their destructive urges into something beneficial.
So keep on keeping an eye on the little things. They generally do the most damage. Weakness can be a great strength, as they say. If you find bugs, report them. Help make the world a better place by breaking things. Who could ask to be paid (if not monetarily, then with the respect and/or gratitude of your peers) for anything more fun than that :)
Cheers,
, Mike
linux unix internet technology
[フレーム]