When you first installed Ubuntu, you created a user account for your-self. You were allocated a tranche of space to save your personal data
USERS,PASSWORDS AND FILES 23
Drive letters and Ubuntu
Ubuntu doesn’t use drive letters. The root of the file system, normally indicated by C:\ within Windows, is indicated by a single forward slash (/) in Ubuntu. Thus you’ll see a path like /usr/share/doc/in Ubuntu, rather than something likeC:\Program Files\Microsoft Office within Windows. Whereas Windows uses a backslash (\) to separate directories, Ubuntu uses a forward slash. Other than that, there are no real differences.
But if there are no drive letters then how are things like addi-tional hard disks or USB key sticks accessed? They’remounted.
This is the magical process of “plumbing through” the contents of a non-Ubuntu file system to a particular folder. For exam-ple, when you click the Windows entry on the Places menu, the contents of the Windows partition will be accessible by browsing the /media/disk/ folder. It’s nearly always the case that empty and specifically-created directories are used for mounting, but if there was anything already in the/media/disk/
folder it will temporarily disappear, until the Windows partition is unmounted. In theory, any file system you want to access has to be mounted, including things like shared network folders, or the CD/DVD-ROM drive. It’s nearly always done automatically.
Unmounting is done by right-clicking the desktop icon of the mounted file system and selectingUnmount(or similar—the pre-cise language used varies depending on what you right-click).
Rather confusingly, to unmount at the command-line you have to use theumountcommand—that’s unmount without the “n”.
(/home/username) and a desktop environment was automatically config-ured for your use.
Yours is an ordinary, unprivileged user account. You can administer the system but only if you “borrow” administrative powers. When man-ually typing commands this is done by preceding them with eithersudo, in the case of command-line programs, orgksu, in the case of GUI pro-grams. You’ll then be prompted for your login password. Type it cor-rectly and the application will run with administrative powers. Simple as that.
Some GUI programs on the System -> Administration menu automati-cally request administrator powers by popping up a password request
USERS,PASSWORDS AND FILES 24
Figure 2.2: Some commands need administrator powers
dialog box, while others require you to click the Unlock button some-where within their program window. This will then pop-up a similar password request dialog box. An example of such an application is the Users and Groupsprogram on the System -> Administration menu.1 If you try to run certain commands without borrowing admin powers, you’ll see an error message of some kind, as shown in Figure 2.2. The reason you’re not allowed to run around the system and do what you want unhindered (like in, say, Windows XP) should be obvious: admin-istering the system brings the possibility of breaking it. The password request also reminds or informs you that the command you wish to use has the potential to really mess things up.
What sudo or gksu actually do is borrow the root user’s power. Effec-tively, for the short time the command in question is running, you become the root user.
The root user is another type of account. If you were to log in as root user, you could do anything, unhindered.
1. Eventually all the system administration tools will have anUnlockbutton. This is part of Ubuntu’s newPolicy Kitfeature that introduces better security by only giving certain aspects of a program administrator powers, rather than all of it.
COMMAND-LINE ORGUI? 25
But, unlike most versions of Linux, Ubuntu doesn’t let you directly login as the root user. It forces you to usesudoorgksuto borrow root powers.
Again, the reasoning behind this should be obvious: there’s simply less chance of damage. You can’t switch to root user and then forget you’re root, perhaps issuing a drastic command that breaks the system.
The idea of root and ordinary users pervades the entire system. All files—even operating system ones—are “owned” by a user. That user can then set access rights for him/herself, the group he/she is in (all users are also members of a group), and also anybody of the system, regardless of what user they are or group they’re in. For example, a user could set a file so that it can only be read by and written to by herself. Or she could add the ability for members of the group she’s in to read it, but not write to it.
All of this might sound strange if there’s only one user on the system (yourself!) but it’s just how Linux works. There is some logic behind it; it should come as no surprise to learn that most operating system files are owned by root. This is why it’s nearly always necessary to borrow root powers when editing configuration files,2 or doing stuff like installing software.
It’s not only files that can be owned and have restrictive permissions set on them. Directories can too, and this can be used to stop unauthorized users even viewing the list of files in some directories.
The end result is that, for many of the tips that make up this book, you’ll need to enter your password to carry them out. You’ll need to precede commands with eithersudoorgksu, or just type your password when prompted. I point this out in each tip, so it’s not something you need to add-in yourself. However, it’s definitely something you should know about.