Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
There is something which has always puzzled me regarding scripts and I wonder if anyone would kindly take the time to explain this.
I have a script called example.script I make this executable by chmod u+x example.script. So why does the script only execute when I type ./script.example and not when I type in just the script name (even when I am in the script's home directory) ? Does bash not look in in the current directory first prior to searching the $Path for the said executable ?
I am sure that on some unix systems I could run a script ( if it was in my current directory) just by typing its name even though its location was not in the $PATH .
I think in some shells you may be right. For example I *think* the Solaris machines I sometimes use allow that. But in Bash I've always found the ./ necessary for items that aren't in $PATH. There may be a way to change this , but it would probably be more effort than just typing ./ when you want to run a script.
In many distributions, $HOME/bin is in path, so perhaps storing them there will add this functionality for you. If not, you can add it yourself in $HOME/.bashrc by adding (or maybe creating the file with)
The /tmp directory is world writable. It has the sticky bit set so that one user can't delete another users files. Imagine that the /tmp directory is getting full and you enter it as root to delete files there. If a regular user created a program by the same name as "ls" or "rm" that would also install a root kit, then you would be toast just from listing the files. The fake ls command might call the real one so you wouldn't notice, and might in the background install it's own version's of "ls" and "ps" to hide it's presence. Another trick is to name a program after a common misspelling like cd.. .
If you had "." in your path it might run the command from the local directory by mistake. This may even be done by a background script if the CWD is /tmp.
I read where a company was touting their system as super-secure at a trade show. A kid saw that "." was in the PATH and guessed correctly that that was the case for ROOT as well. He wrote something in /tmp and then came back later asking the salesman a question that required the salesman to list files in /tmp. The salesman did this as root. The kid wasn't malicious in what he wrote in the ten seconds or so he was on the machine. I think it simply cleared the screen and put up a false message about formatting the hard drive.
This may also be the oldest hack on Unix as well. If you used a machine and "." was in the path, it was probably added by a lazy admin for convenience. I bet that the root users PATH variable wasn't like that however. Even so, if as a regular user you cd to any world writable directory, or even if a GUI program launches with a world writable directory as it's CWD, you could have your own files trashed. An OS is easy to replace by reinstalling. Your data might not be.