LPI: Learn Linux and get certified. Part 8 Links and Permissions


We’ve come to the final part of this series, and it has been great to read your feedback. We’re really glad you’ve found it useful! Whether you’re an intermediate Linux user looking to find employment with your newfound skills, or you’re a home desktop dabbler who merely wanted to learn more about your operating system, we wish you good luck.

It has been really enjoyable to write this too: because Linux is totally open and free, it’s great that we can all delve under the hood and find out what makes it tick. Anyone can become a guru, with the right time and patience. There are just a few final topics that we haven’t covered yet, so we’ll get them sorted out here. We’ll take a look at filesystem links, how permissions affect the security of a filesystem, and then limiting disk space usage with quotas.

Because the first instalment in this series was a good eight months ago, you might be feeling a little fuzzy with the original topics, so go to the Magazine/LPI_quiz section of the disc or visit www.linuxformat.com/files/lpiquiz.txt to test yourself. Have fun, and happy Linuxing!

Section 1: Creating links

All good system administrators try to avoid duplicating resources. Not only is it wasteful, but it leads to confusion too. For example, you might have a scenario where a file needs to be visible in two different places on the filesystem. You could have a text file that you’re editing in your home directory, and want it to be visible to users of your web server in /var/www/textfiles/.

Now, the most basic way to deal with this is copying: periodically, you copy the file from your home directory to /var/www/textfiles/. That does the job, but it leads to two problems: If you forget to copy the file, the versions get out of sync. What if another admin wants to edit the file, and edits the /var/www/textfiles/ one instead?

We can deal with this using symbolic links. These are extremely tiny files that contain little more than pointers to another file on the filesystem – they’re a lot like ‘shortcuts’ in the Windows world. Symbolic links exist on their own, independent of the file they point to, so there’s no harm in removing them. First though, let’s set up a link as an example. Create an empty file like so:

touch myfile

This creates an empty, zero-byte file just for demonstration purposes, put you can point symbolic links to just about anything. Now we create a link to it using the ln command as follows:

ln -s myfile mylink

The order of the command is important here: we have the -s flag to state that the link is symbolic (more on another type of link in a moment). Then there’s the target file, ie the one the link should point to, and then the name of the link file itself. Here we’re just working in the current directory, but you can specify full paths to files. You can even create links to directories. If you enter ls -l --color at this stage, you will see that the link file has a different colour, like in the screenshot. This detailed list view shows the target of the link with ->.

So far, so good. But how does it work in practice? Well, try editing the mylink file – open it in Nano, Vim, gEdit or whatever takes your fancy, enter some text and save it. Back at the command prompt, enter ls -l again, and cat myfile, and you’ll see that despite editing mylink, all the changes to the stored data actually happened in myfile. Programs don’t care about the links – they’ll just look at the files they point to, and work on them.

Where did that file go?

There are two main ways to hunt down files on a Linux filesystem: find and locate. It might sound silly to have two commands with ostensibly the same function, but there’s a crucial difference between the two. First, let’s look at find. This is a small utility that traverses the filesystem, printing out paths of filenames that match your search terms. For instance, in the root (/) directory enter:

find . -name “linux”

This will search the current directory, all subdirectories (and subdirectories of those – so the whole filesystem in our case) for files that contain the word “linux” in the name. (As you might recall from previous tutorials, the single . full-stop character refers to the current directory. You can of course use a different path here.)

Find has various options which you can explore in the manual page (man find), such as being able to search by different file types. However, it has one major flaw: it’s slow. Very slow, indeed, on big installations when you have many thousands of files. There’s an answer in this, however, in the form of locate. Whereas find merrily trawls through a filesystem to locate things, locate consults a pre-made database. This makes its searches lightning quick:

locate linux

Locate also has a downside, though, and that’s when things change on the filesystem. It’s possible for locate’s database to get out of date, so you can’t guarantee the results. Locate’s database is updated using the updatedb command, and this is typically run by a daily Cron job (scheduled task). Have a look in /etc/cron.daily for a file like locate, mlocate or updatedb, and you’ll see in its contents that it runs commands to update the database; this can usually be found in /var/lib/mlocate. Have a look at /etc/updatedb.conf for settings, and note in particular that you can avoid having certain filesystems and mountpoints added to the database, to avoid painfully slow scanning of your DVD-Rs, for instance.

Avoiding catastrophes

Well, most of the time. There are some precautions against absolute disaster. Enter rm mylink and the symbolic link file will be removed, not the file it points to; otherwise you’d never be able to get rid of the symbolic link!

There’s also another scenario that can crop up here. Go through the same process again, so you have myfile and mylink, and then delete myfile. Now the file that mylink is pointing to doesn’t exist – it’s a broken, dangling link. Enter ls -l --color and you can see it’s a warning shade of red, and file mylink tells you that it’s broken.

Symlinks provide a great deal of flexibility and customisation, and you can see this by looking in /etc/alternatives (if your distro has it). That directory is full of symbolic links to programs, and lets you have multiple versions of software on the same machine. For instance, there are different versions of Java out there, but with symlinks you can point the generic java command on your machine for the particular version you want to use.

Or you might want to have an experimental version of GCC installed; you can symbolic link (or ‘symlink’) /usr/bin/gcc to the experimental version while you build some stuff, and then symlink it back to the original afterwards.

A symbolic link in action – when we append text to it, we really append text to the original file it points to.

A symbolic link in action – when we append text to it, we really append text to the original file it points to.

The harder side of links

There’s another type of link, though, and it’s considerably more powerful: a hard link. Whereas a symbolic link contains a filename for its target, being a separate file on the filesystem with a pointer inside, a hard link is an extra entry in the filesystem data.

If this is a bit hard to understand (and it confuses many people who aren’t familiar with filesystems), consider how a filesystem works. It’s full of data, and there’s a table at the beginning saying which files own which pieces of data.

Now, imagine that myfile is a plain text file whose data begins at position 63813 on the hard drive (or any random number). If you create a symbolic link to myfile, a whole new file is created with a shortcut inside that says “Hello, I actually point to myfile, so go over to that one. Thanks”. Conversely, when you create a hard link, no new files are created. Instead, the filesystem table is updated so that mylink also points to position 63813 on the drive. There aren’t two separate files here; just two filenames that correspond to the exact same place on the drive.

In summary: symbolic links point to other files; hard links point to other data areas on the disk. In practice, this means they work quite differently to symbolic links. For instance, create a text file called foo with some text in and make a hard link to it like this:

ln foo bar

(You’ll notice that we omit the -s flag for a hard link.) Enter rm foo to remove the original file, and then ls -l. You’ll notice that bar still seems to be OK, and if you cat bar the text contents are there. How can that be? Well, when you removed foo you just removed its entry from the filesystem table; you didn’t wipe the data from the disk itself. That’s because another entry in the filesystem table is also pointing to that data – bar.

Make sense? Hard links have limitations (they can’t span across different filesystems) and are rarely used, so you don’t have to wrack your brains with the technical underpinnings. But it’s worth having an overview of what’s going on. Symbolic links are far more commonly used in Linux installations, however, and being able to create them means you can remove a lot of fluff and duplication from your setups. You’ll see many of them in your Linux travels, as lots of packages set them up.

Section 2: The power of permissions

Permissions are an essential part of any modern operating system. It’d be crazy if every user could access, modify and delete every file on the filesystem. Even on a single user machine, like many desktop PCs, it’s vital to have a good system of permissions: they prevent a lot of accidents. Because a normal user account can’t modify files in /etc and /boot, for instance, a typo at the command line can’t destroy critical startup components and make the system unusable.

Then there’s the security aspect as well. Because normal users are mostly limited to altering files in their home directory, if Joe Bloggs downloads and runs a dodgy malware script, it can only affect his own personal files. Sure, that could lead to Joe’s photo collection being wiped (unless he had good backups, of course), but at least it can’t change the way the OS fundamentally works. Permissions in Linux, as in many Unix-like systems, are divided into three groups:

  • Read access
  • Write access
  • Execute access

You can turn these on and off independently. For instance, as a normal user, most files in /etc have read access but not write access. Most files in /bin and /usr/bin have read and execute access for normal users, but not write access. As a side note, directories need to be both readable and executable in order for them to be accessed.

Entering ls -la shows all the files in the current directory, with their permissions down the left.

Entering ls -la shows all the files in the current directory, with their permissions down the left.

Get into groups

Now, permissions are organised into groups. There’s the owner of the file, the group that the owner belongs to, and other (unrelated) users. Let’s cover these step-by-step. In a terminal, enter the following commands:

touch foo
ls -l foo

This creates a new file called foo and shows its default permissions state. The bit you want to look at is -rw-r--r--, at the start of the line. Let’s break this up into its component parts:

  • - The first dash is the type of file. It’ll say d for a directory, l for a link, or - for a regular file.
  • rw- The first bunch of three characters show the permissions for the owner of the file. Here, rw means read and write, and the dash means that it’s not executable. (rwx would mean read, write and execute.)
  • r-- The next trio is for the group, here showing that the file is readable by the group, but not writable or executable. Linux user accounts can be joined together in groups, so that you can give certain users certain permissions. For instance, you might have 50 people accessing your machine, but you only want 10 of them to have write access to a particular folder. You can put these 10 into a group and then give that group write access to the folder. More on groups in a moment.
  • r-- The final trio is for other users, ie anybody else on the system. It’s just readable; the w and x (write and execute) bits are not set.

Some combinations of permissions might seem strange, but you never know when they could be useful. For instance, you could set a binary program to be executable but not readable, so users can run it but not look around inside it (eg with the strings tool).

Restricting disk space with quotas


On a multi-user machine, you may have a scenario where you want to restrict disk space usage. A quick-hack way to do this would be to limit the size of the /home partition, but that’s very inflexible. A better approach is to use disk quotas. Setting these up is a rather involving process and varies from distro to distro – so instead of including 2,000 words with every complicated caveat here, we’ll explain the essentials so you know what to expect. You can then Google specific instructions for your distro (or if your distro’s docs are very thorough, like Gentoo’s you’ll find information there).

Quotas can restrict disk usage for users or groups. You will need to edit /etc/fstab – the file that controls how filesystems are mounted – to add usrquota and grpquota options for the relevant filesystem. You mount the filesystem in single-user mode, create aquota.user and aquota.group control files, and then add a quotacheck command to Cron, to periodically check if users are overrunning their allowance. Finally, edquota sets up the specific quotas for users. You can use quotaon and quotaoff to enable and disable quotas, and repquota to get a report of disk usage.

New chmodel army

To change permissions we use the chmod utility. This works by combining a letter for the type of user along with a plus or minus sign and the required permission. The user types are:

  • u = user who owns it
  • g = users in the group
  • o = other users
  • a = all/everyone

So, for instance, to change the file myscript so that only the owner can execute it, enter:

chmod u+x myscript

To change the file so that nobody can read it (except for root), use:

chmod a-r myscript

Note that you can do chmod operations on multiple files, using the -R flag to recurse into directories. See the manual page (man chmod) for some more information on the command.

So, that handles permissions, but how about owners and groups? There’s a similar command called chown (change ownership). This takes a user and group separated by a colon, like this:

chown steve:vboxusers myfile

If you ls -l the file now, you’ll see that its owner is steve and its group is vboxusers. To see a list of available groups on the system, look in /etc/group, and to add a user to a particular group, have a look at the usermod man page (specifically, the -a and -G options). While chown can modify user and group information in one command, there’s a standalone chgrp tool just for the group bit.

If you ever have trouble entering a directory, make sure that its executable permission is set!

If you ever have trouble entering a directory, make sure that its executable permission is set!

Of course, you have to have the appropriate ownership rights of a file or directory to make changes to it. Otherwise, any old random user could snag normally blocked-off directories such as /root and claim it for their own!

Take off your mask

One quite advanced feature worth being aware of is umask. This is a shell setting that determines the default permissions created by a user.

The default permissions in most Linux distributions are that files are readable and writable by the original author, and just readable by users in the group and other unrelated users. Changing this is accomplished with the umask command. For instance, enter this in a shell prompt:

umask a+rw

Now create a file, like touch blah, and with ls -l blah you’ll see that the file is readable and writeable by everyone. You can add use this to customise user accounts via their Bash configuration files (~/.bashrc) or system-wide (/etc/profile).

You might see umask and other permission tools use numbers rather than the symbols we’ve discussed before; these are octal (base 8) numbers and beyond the scope of this guide, but if you’re curious then Wikipedia has a good explanation at http://tinyurl.com/68e8lp.

Where to go from here

Congratulations on reaching the end of the series! It’s been hard work at times, but we’ve covered an enormous amount of ground. At this stage, you’re fully equipped to administer Linux machines, and have a wide range of knowledge across many areas of the operating system.

Even considering some of the advanced subjects, which aren’t used on a day-to-day basis, you know what the terminology means and won’t get lost when you come across a guide using it.

So, what’s the plan now? Well, we recommend going back over the previous tutorials (you can find them on the disk in the Magazine/PDFs section), skimming over the sections and making sure you’ve internalised everything. Then open up the quiz in Magazine/LPI_quiz and test your knowledge. Don’t fret if you get anything wrong – there’s a lot to take in, so just go back to the relevant tutorial and try the commands again.

When you’re happy with your progress, visit www.lpi.org and look at the certification options. The LPI has various partners performing exams over the internet or in person. If you want to get a job in Linux, this is the way to go. Good luck, and let us know how you get on!

First published in Linux Format

First published in Linux Format magazine

You should follow us on Identi.ca or Twitter

Your comments


I just wish LPI didn't cost so much, I would love to do the certification but there is no way I could afford it as a student on top of my university fees!


I am disappointed with the number of inaccuracies in this article. 'find . -name "linux"' doesn't find "files that contain the word “linux” in the name", it finds files that *are named* "linux". The correct command would be 'find . -name "*linux*"'. That's one of ~3 errors (and I didn't read the whole thing).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Username:   Password: