The (almost) only place on the harddrive that normal users (non-root) can write to is their home directory, which is /home/user_login_name.
This "home" directory is for all user files: settings, program configuration files, documents, data, netscape cache, mail, etc. As a user, you can create subdirectories under your home directory to keep yourself organized. Other users cannot read your files or write to your home directory unless you give them permission to do so.
Normal users can also see, read and execute many other files on the system (besides their home directory), but normally they cannot modify or remove (delete) them.
The "root" (also called "super user") is a special administrative account that has the power to modify any file on the system. It is not a good idea to habitually work on your system as root--if you do so, your mistakes can cost you dearly. Set up and use a normal user account for everyday work for yourself, another user account for your son, and yet another for your wife. The root account is typically the only account that exists on Linux after the initial installation. Thus you have to explicitly create "user" accounts for normal work for you Linux system.
A user account can be created by "root" using, for example:
[type the password for the user joe]
[retype the password for the user joe so as to avoid mistakes]
In the example above, first I logged in as root. Then, on the command line, I issued the command "adduser" with the parameter (argument) "joe". This created the account "joe" on my Linux computer. Then, I issued the command "passwd joe" to change the password for the user "joe" to something fairly secure. Now, I can tell "joe" what her initial password is, and she can login and change the password to her liking. Please note that the account name (user login name, "joe") and the password are case-sensitive.
Root can change any user's password, although s/he cannot read it. [Passwords are encrypted using a one-way encryption algorithm and only this encrypted version is stored on the system, in the file /etc/passwd (older systems) or /etc/shadow (newer systems), and the "open" version of the password is never stored. When you login, the password you type is encrypted again using the same one-way algorithm and compared with the already encrypted version stored in /etc/passwd or /etc/shadow.]
The separation of the administrator and user makes Linux systems secure and robust--it even makes viruses under Linux difficult (the programs that a user runs can write only to his/her own directories, and therefore cannot affect the vital parts of the operating system).
It is customary that the user changes his/her password immediately after the first login, for example:
(current) UNIX password: pass_OLD
New UNIX password: pass_NEW
Retype New UNIX password: pass_NEW
In reality, the password will not appear on the screen as you type it (for security reasons). Take your time if you are changing the password for the very first time--it can be difficult to type "blind".
On the Linux system, the same password is used to:
login on the text terminal,
login from a graphical (GUI) screen into your desktop (KDE or GNOME),
unlock a locked text terminal,
unlock a password-protected screen saver on a GUI (for example, KDE or GNOME).
Weak passwords are probably the most common source of security problems. Even at home, you may expose yourself to serious trouble because somebody may be able to hack your computer when you browse the Internet and read/delete your files, or use your computer to do something really nasty to the local police computer network. Therefore, keep all your login names/passwords secure, even at home. Once somebody logs into your computer (even as an ordinary user), he may find it quite easy to gain root access (depending on how well-maintained/up-to-date your system is vs. how good a hacker s/he is).
Here are some examples of hazardous passwords:
No password (possible!).
The word "password" (wow, this one is really weak!).
Your login name (The login and the password the same? Hmm.).
Your first name or the first name of your daughter, son, husband, wife, girlfriend, or any other first name. The number of first names in use is quite limited--just check the paperback book "what to name your baby". Don't assume that a first name you think of is secure because you are from India--Canada is really a multinational society and the typical namelist seems to cover all kinds of first names.
Your last name or any other last name. The number of last names is surprisingly limited! Just check the US census data to see that your "rare" last name from the abamamahaba island is very well represented in the US 89,000 of the most frequent last names (e.g., http://www.census.gov/genealogy/www/freqnames.html). Or just check the Toronto telephone book. Another proof that we are all one family :))
The nickname of your dog, wife, canary or computer. (Very few nick names humans use, much fewer than last names!)
Name of your favourite sports team, celebrity, toothpaste, or detergent. Avoid names of popular soccer teams like fire. Same with rock bands (music).
Date of your birth, social security number, etc; Sequences of digits can be easily probed.
Name of your company, department, workgroup, etc.
Password written in the calendar on your desk or on the side of your computer.
A password which you also use in an insecure public place, for example an Internet store or a mailing list. In general, you should use different passwords for places controlled by different organizations.
Any word which is in the English dictionary. The English dictionary does not contain as many words as it might seem. A not-so-skillful hacker can easily set a program to encrypt all dictionary words (100,000? that's under 1 MB!) and then compare all the encrypted strings to your encrypted password. As a matter of fact, tools for the "dictionary attack" are readily available on the Internet. Try the program crack yourself to find how easy it is. Swear words or "cool" (colloquial) expressions make the password particularly vulnerable for cracking.
Any other word, last name, first name, pet or swear word, no matter in what language. For a cracker, to cover most languages is only a small overhead if he already covered one. How many significant languages are out there? 40? The cracker just grabs a few more files and appends it to his cracking list. The point here is that the subset of words that humans normally use if far far below the theoretical limit of the random combination of characters.
Any of the above with an addition of a number/letter at the beginning or the end. "yuoping1" is really a very weak password.
A good password is relatively long (minimum 6 characters, some experts even recommend minimum 10 characters), contains a mixture of letters (upper and lower case, if possible), numbers and special characters, and is changed quite regularly (8-16 weeks?).
Unfortunately, the better the password, the harder it is to remember. I solved this problem for myself by taking 10 minutes to invent my personal password "scheme". Say, I always start and end with the monkey (@) sign, and use two words connected with an exclamation mark, the last letter of each word is capitalized, e.g., "@whitE!housE@". Seems like an adequate password, and it is easy to remember once I know what my password rule is. If you are a memory genius, you may consider truly excellent passwords generated with mkpasswd :))
The system administrator can set the password policy (minimum length, requirement of special characters, password expiry) through the utility included in this configuration program (run as root):
under the menu "user account"-"policies"-"password & account policies". Normal users won't be able to set a password which is too short, is a dictionary word, or does not contain the prescribed number of non-alphanumeric characters (but root can change any password to anything s/he likes, s/he will only be given a warning).
Also make sure that any file that contains any password of yours (e.g., /root/.kde/share/config/kppprc) has proper, secure permissions so that it cannot be read by anybody. For example, most likely you want:
chmod 600 kppprc
If you use an "over the phone" Internet connection for just a couple of hours a week, you may be fine even with a relatively weak password on your system. But please really reconsider your system security if you use a cable modem, or are otherwise connected to the Internet for a significant amount of time.
Most computer semi-literate use amazingly weak passwords. "Around 50 percent of computer users base passwords on the name of a family member, partner or a pet. Thirty percent look to a pop idol or sporting hero," reports CNN (http://www.cnn.com/2002/TECH/ptech/03/13/dangerous.passwords/index.html). Please note the underlined base. Appending a digit to an obvious word hardly makes the password more secure.
Even if I never forget any passwords, I would still study this issue in detail because it can give me a hint on how my mother might be reading my ICQ chats history :-)
First method. The easiest way to solve your "forgotten root password" problem is to boot your Linux in the single-user mode, namely at the "lilo"prompt (during bootup) type:
This will make you "root" without asking for a password. Now, being root, you may change the root password using this command (no knowledge of the old password required):
If it strikes you as insecure, that's because no computer system is secure if other people have physical access to your hardware. Nevertheless, I did not like the "linux single" hole on my home computer and plugged it by adding the following lines to my /etc/lilo.conf file (at the end of the "image=" section):
[This "lilo" password is required when, at the LILO prompt during bootup, somebody enters the word "linux" with any parameter (normal bootup without any parameters will still be possible without a password).] For the changes to /etc/lilo.conf to take effect, I must re-run the command lilo . Since my lilo password is not encrypted, I must make /etc/lilo.conf readable only for root:
chmod 600 /etc/lilo.conf
Second Method. Another way to solve the "lost-root-password" problem is to boot your computer from the Linux boot diskette or the CD. Then find your Linux root partition on the hard drive, mount it, and edit the file /etc/shadow. (I can do it because after booting from the floppy, I become root without being asked for a password.) In the password file, I erase the encrypted password for root (for example, using the pico editor), so it is empty.
Information about a user account is kept in plain-text files: /etc/passwd and /etc/shadow.
The file /etc/passwd contains the "world-readable" information about all accounts on my computer Each line in this file contains information about one account. Each line has 7 colon-delimited fields (this means 8 entries separated by colons): login name, the letter "x", the numerical user ID, the numerical primary group ID for the user, a comment field (for example, the full name of the user), the user's $HOME directory, the name of the shell (meaning the program that is run at login).
The balance of information about accounts on my computer is stored in the file /etc/shadow. This file is more secure because normally only root can read it. In this file, each line describes "shadow" information about one account, and has 9 colon-delimited fields: login name, encrypted password, days since Jan 1 1970 that password was last changed, days before password may be changed, number of days after which the password must be changed, number of days before password expiration to warn the user, number of days after password expiry that account is disabled, number of days since Jan 1 1970 that account is disabled, and a reserved field.
Some (older) UNIX or Linux systems do not contain the file /etc/shadow and store the encrypted user password in the second field of each line of the file /etc/passwd (the field which on newer systems contains just the letter x).
For example, my /etc/shadow entry for "root" account may look like this:
and after the password is erased, it looks like this:
Now, the root account has no password, so I can reboot the computer and, at the login prompt, type "root" and for password just press ENTER (empty, no password). After a successful login, I immediately set the password for root using the command:
Apparently, despite deleting the password from /etc/shadow , the Debian distribution will not let you log in "passwordless" (enhanced security?). In such a case, what needs to be done is to replace the password in /etc/shadow with an encrypted password from another account, where you know the password. After that, you can login since you know the password.
E-mailing an encrypted password may be also a secure way to set up an account for somebody remote: "I am setting up an ftp account for you on my server. Email me your encrypted password." After you receive the encrypted password, you insert it into the appropriate field in /etc/shadow. Now, the user can log in, since she knows the password, but nobody else can.
To make the "floppy access" to my system a little bit more difficult, I considered running a computer without a floppy drive :-) Unfortunately, Linux CDs are bootable these days. I set up my boot sequence (in the BIOS setup) so that the system boots from the hard drive before floppy and CDROM are tried, and added an "administrative" password on changes to the BIOS settings. Still, I worry that these BIOS passwords are very easily crackable, or that one could remove the small battery that sustains the BIOS setting. One could also remove my harddrive and connect it to another computer for reading :-) . I am thinking about installing an "encrypted file system" which is now available on Linux, but considering all the trouble associated with it, perhaps I will settle on locking my room :-) . If all this sounds paranoid to you, it probably is--it just illustrates the point there is little computer security, even under Linux, if the potential cracker has a physical access to your hardware.
If a regular (non-root) user forgets his/her password, this is not a problem since root can change any password. For example (as root):
will prompt for a new password for the user "barbara" (no knowledge of the old password required by root). If a regular user (non-root) wants to change his/her password, s/he will be asked for the old password first. (This is a security feature so nobody changes your password if you have left your terminal unattended.)
A user account can be temporarily disabled or permanently removed.
To temporarily disable (lock) a user account, there is no need to change his/her password. Just put an asterisk "*" at the beginning of the second field (before the encrypted password) in the file /etc/shadow. The "*" means that no login is permitted for this account. When you want to restore the account, you just erase the asterisk and the user account is back in operation, with its old password.
Here is an example entry from the file /etc/shadow with the password disabled for user "peter":
I could also lock a user account with the following command:
passwd peter -l
and unlock it with
passwd peter -u
To irreversibly remove a user account from my home computer, I do the following:
login as root
change my identity to the user to be removed, to check if there is any new important mail:
delete the user account and group
Remove the user affiliation to any supplementary groups:
usermod -G doomed_user_login_name doomed_user_login_name
force-delete the user home directory with all its contents including any subdirectories:
rm -fr /home/doomed_user_login_name
Linux (the same as any UNIX) is a secure, multiuser operating system, and this creates a level a complexity with "files permissions". Trouble with file permissions can lead to unexpected and nasty problems. Understanding file permissions is of uttermost importance to be able to administer any multiuser operating system (be it UNIX, WinNT, or Linux). My advice would be: learn the system of Linux (or any UNIX) file permission conventions; you will not regret it.
File owners. Each file (or directory) belongs to an owner (normally a login name) and to a group. The owner is typically the person who created (or copied) the file. The group often consists of one person--the owner, and has a name identical to that of the owner, but it does not need to be so. A file can be removed (erased) only by the owner of the file, or a member of the group that owns the file, or the root. Other users, however, may be able to modify or erase the contents of the file if they are given permission to do so--read on. The owner and group that owns the file will be shown in the output from the ls -l command (="list in the long format"). For example, the command:
ls -l junk
produced this output on my screen:
-rwx------ 1 yogin inca 27 Apr 24 14:12 junk
This shows the file "junk", belonging to the owner "yogin" and to the group "inca".
The ownership of a file can be changed using the commands chown (change owner) and chgrp (change group), which are normally executed by root:
chown peter junk
chgrp peter junk
ls -l junk
After executing the above 3 lines, the command ls-l junk produces this output on my screen:
-rwx------ 1 peter peter 27 Apr 25 20:27 junk
Changing file ownership comes handy if you move/copy files around as root for use by other users. At the end of your housekeeping you typically want to hand the file ownership over to the proper user.
File permissions. Now, an owner of a file can make the file accessible in three modes: read (r), write (w) and execute (x) to three classes of users: owner (u), members of a group (g), others on the system (o). You can check the current access permissions using:
ls -l filename
If the file is accessible to all users (owner, group, others) in all three modes (read, write, execute) it will show:
Skip the first "-" (it shows the type of file, and is "-" for normal files, "d" for directories, "l" for links, "c" for character devices, "b" for block devices, "p" for named pipes i.e. FIFO files, "f" for stacks i.e. LIFO files). After the initial "-" character, the first triplet shows the file permission for the owner of the file, the second triplet shows the permissions for the group that owns the file, the third triplet shows the permissions for other users. A "no" permission is shown as "-". Here is an output from the ls -l command on a file that is owned by root, for which the owner (root) has all permissions, but the group and others can only read and execute:
drwxr-xr-x 2 root root 21504 Apr 24 19:27 dev
The first letter "d" shows that the file is actually a directory.
You can change the permissions on a file which you own using the command chmod (="change mode"). For example, this command will add the permission to read the file "junk" to all (=user+group+others):
chmod a+r junk
In the command above, instead of "a" (="all"), I could have used "u", "g" or "o" (="user", "group" or "others"). Instead of "+" (="add the permission"), I could have used "-" or "=" ("remove the permission" or "set the permission"). Instead of "r" (="read permission"), I could have used "w" or "x" ("write permission" or "execute permission").
Second example. This command will remove the permission to execute the file "junk" from others:
chmod o-x junk
Instead of letters, one can also use numbers to specify the permissions. To understand how it works, look at this:
The total permission for a class of users is the sum of the three. Thus:
0 = no permissions at all(neither to write, nor to read nor to execute)(common)
1 = execute only (seems unusual)
2 = write only (seems unusual)
3 = write and execute (seems unusual)
4 = read only (common)
5 = read and execute (common)
6 = read and write (common)
7 = read, write and execute (common).
The permission for all three classes of users (owner, group, others) is obtained by gluing the three digits together one by one. For example, the command:
chmod 770 junk
will give the owner and the group the completto of permissions, but no permissions to others. The command:
chmod 666 junk
gives all three classes of users (owner, group, others) the permissions to read and write (but not execute) the example file named "junk". Please note the "666". It is quite often used and, for at least one person I know, it is proof that Linux (any UNIX for that matter) is the work of the devil >:-0.
chmod 411 junk
would give the owner the permission to read only, and the group and others to execute only. This one does not seem useful, but might be funny, at least for those North American Linux users who dial 411 (telephone number) for directory assistance. Mail me if you can think of any other funny permissions (perhaps 007?).
The numerical way of representing file permissions is called "octal" because the numbers have the base 8 (the decimal system's base is 10). The highest digit in the octal system is 7 (the octal system has eight digits: 0 to 7, analogous to the decimal system having ten digits: 0 to 9). The octal representation is really a convenient notation for the binary representation of file permissions, where each permission is flagged as "set" or "denied" with a one or zero and the total is represented as a string of zeroes and ones, as in this diagram:
user class: owner group others
example permissions: rwx rw- r--
absent permissions: --- --x -wx
binary representation of the permissions: 111 110 100
octal representation of the binary: 7 6 4
The meaning of the permissions is different for directories than it is for "normal" files. For normal files: r=permission to read the contents of the file, w=permission to modify the contents of the file, and x=permission to execute the file.
For directories: r=permission to list the filenames in the directory, w=permission to create or delete files in the directory, and x=permission to access the directory. Otherwise, the permissions are set the same way for directories as they are for normal files.
Default file permissions with umask. When a new file is created, it is given default permissions. On my system, these are:
This means that files created by a user can be read and written by this user; the group and the others can only read the file. Still, on my default RedHat system, users cannot read the files in the other users' home directories because the permissions on the home directories are:
I can check the default file permissions given to my newly created files using:
(The option "-S" stands for "symbolic" and tells umask to display the permissions in an easy-to-read form, instead of the default numeric mode.)
I can change the default file permissions for newly created files using a command like:
which will give the owner the read and write permissions on newly created files (r+w), and no permission to the group and others.
Using numbers to set default permissions with umask is more tricky. The number shows the permissions that you take away for users (opposite to chmod). Thus:
will give full permissions to everybody on newly created files. The next example gives read and write permissions to the owner, and zero permissions for everybody else (seems that's what one might want):
To make the settings permanent for all users on the system, adjust the appropriate line(s) in the file /etc/profile.
The MP3 player might not be given enough processor power (it requires a lot of it). It could be that your computer is lousy. Or you might be running too many cpu-intensive programs at the same time. Or, most likely, you may need to run the player with a higher priority. (The priority of a program can be set with the command nice -- see man nice or info nice). Try to run the player as root--programs run by root are given higher priority than those run by normal users. If this solves the "interrupted music" problem, set the "suid" on the executable so all users are given the "effective user id" of the file owner (normally root) when running it, for example:
chmod a+s /usr/bin/xmms
will do the trick for the xmms program. The output from
ls -l /usr/bin/xmms
on my computer is now:
-rwsr-sr-x 1 root root 908k Feb 22 2000 /usr/bin/xmms
The first "s" indicates that the substitute-user-id (suid) bit is set. The second "s" indicates that the substitute-group-id (sgid) is also set. Thus anybody who executes xmms is given the effective user id of the program owner and effective group id of the owner group, which in the example above is the user "root" and the group "root".
Setting the suid for a program could possibly become a security hole in your system. This is unlikely the case on a closed home network and when setting suid for a program of which the origin is well traceable. However, even at home, I wouldn't suid a piece of code of which the origin is uncertain, even if the setup instructions urged me to do so. Also, it is definitely a very bad idea to suid too many executables on your system--it defies the whole idea of UNIX security.
Some programs do, however, require suid for proper functioning, for example kppp (the popular modem "ppp" connection utility under the KDE graphical-user-interface desktop). This is because they require direct access to the hardware--something only root is allowed to.
If you have constant problems with a smooth performance of your system, or some "real time hardware" (e.g., CD writer) tends to crash, try to reduce the number of daemons on your Linux system. Run (as root) setup (RH specific command) and disable all the "services" that you don't really require. Ultimately, you can switch to the command line, shut down the GUI (command init 3 as root), and then the performance should surely be even better.
For those who need (like) their Linux to be a "universal" operating system (workstation, server, office computer, game box, mulimedia, etc, everything at the same time), there are dedicated Linux kernel patches: "low latancy patch" and "pre-emptive kernel patch" which aggresively atack the "latency" problem that overloaded systems exhibit.[an error occurred while processing this directive]