Once you understand Linux file permissions, the next step on the road to enlightenment is learning how to check the permissions for a file or directory.
If you’ve been through the previous article in this series you’ll have an idea of what file permissions are. Before we talk about how to actually change file permissions we’ll want to look into how we can see what permissions are set on a file to begin with. To do this we’ll use the “ls” command.
A really thorough look at ls and what you can do with it will make a good subject for another article someday. For now, let’s focus on the basics of how to use ls, and what it can tell us about a file’s type and permissions.
First of all, “ls” (the first letter is a lowercase L) is the command you’ll use to see what files are in a directory. It’s a handy command, and you’ve probably used it before. When run by itself, ls will get a listing of the current working directory (essentially, the directory you are “in”). You can also tell the ls command what directory to get a listing of.
A listing of the first few files in /etc on a Gentoo system might look like:
$ ls /etc DIR_COLORS gentoo-release man.conf runlevels adjtime gpm mime.types sandbox.conf apache2 group mke2fs.conf sandbox.d bash group- modprobe.d scsi_id.config ca-certificates host.conf modules.autoload.d securetty ca-certificates.conf hosts modprobe.d scsi_id.config ...
Of course, you’ll eventually want to know more about the files than just their names. Their permissions, for example.
If you want more information about files in a directory, use the “-l” flag with ls to get a long listing.
$ ls -l /etc total 492 -rw-r--r-- 1 root root 4468 Nov 19 2009 DIR_COLORS -rw-r--r-- 1 root root 10 Jun 30 03:29 adjtime drwxr-xr-x 4 root root 4096 Jun 30 03:44 apache2 drwxr-xr-x 2 root root 4096 Nov 19 2009 bash drwxr-xr-x 3 root root 4096 Nov 19 2009 ca-certificates -rw-r--r-- 1 root root 5955 Nov 19 2009 ca-certificates.conf drwxr-xr-x 2 root root 4096 Jul 5 20:37 conf.d drwxr-xr-x 2 root root 4096 Dec 3 2009 cron.d drwxr-x--- 2 root root 4096 Dec 3 2009 cron.daily -rw-r--r-- 1 root root 220 Dec 3 2009 cron.deny drwxr-x--- 2 root root 4096 Dec 3 2009 cron.hourly drwxr-x--- 2 root root 4096 Dec 3 2009 cron.monthly drwxr-x--- 2 root root 4096 Dec 3 2009 cron.weekly -rw-r--r-- 1 root root 611 Dec 3 2009 crontab ...
If you look way over on the right, you may recognize the file names from the previous example. If you look at the stuff before the names, that’s where the file details are. We’ll be concerning ourselves with those bunches of letters and dashes on the left, and the columns that both have “root” in them.
But before going into details about those, one more of the (many) options that can be sent to ls…
One thing to know about ls is that it doesn’t normally want to show you everything. If you want to see any files that start with a period, you’ll need to pass it the -a option. For example, let’s look at a directory listing for root’s home directory on a clean Linux install:
$ ls /root
The nothingness that follows the command isn’t an accident - that’s what ls returns. Nothing. There are no files in /root. Or…are there?
$ ls -a /root . .. .bash_history .bashrc .profile .viminfo
That feeling of betrayal you’re feeling is normal, but we shouldn’t judge ls too harshly. Files that start with a period are usually system files and application settings files, and you usually don’t want them cluttering up your directory listings anyway. But it’s important to know that they’re there, and how to see them. That “.bashrc” file is especially useful to know about, since there are a bunch of user environment settings you can change in there.
If you combine “-l” and “-a” into “-la” you can get all the details of those hidden files:
$ ls -la /root total 24 drwxr-xr-x 2 root root 4096 2009-12-16 01:10 . drwxr-xr-x 23 root root 4096 2010-02-18 10:14 .. -rw------- 1 root root 123 2010-01-21 15:49 .bash_history -rw-r--r-- 1 root root 2227 2007-10-20 11:51 .bashrc -rw-r--r-- 1 root root 141 2007-10-20 11:51 .profile -rw------- 1 root root 868 2009-12-16 00:47 .viminfo
Let us briefly pause to consider the “.” and “..” in both directory listings. They show up because “-a” is very thorough and leaves nothing out. The “.” refers to the directory itself. You can type “cd .” and you’ll change directory right back into where you were to start with. It’s pretty convenient when you’re running a command and you want it to refer to your current directory (like when you want to copy a file there).
The “..” refers to the parent directory. If you type “cd ..” you’ll wind up in the directory above the one you’re in, in the filesystem hierarchy. In this case, we’re in /root, so “cd ..” would take us into “/”, the very top of the hierarchy.
Now we’ll look at that first mess of letters and dashes in more detail. We’ll start with the letter or dash in the first slot.
In the examples above, the first character in each long listing was either a “d” or a “-”.
When you see a “-” in the first slot, that means the file it’s referring to is a regular file. That’s the sort that you’ll usually work with when you’re saving some text or running a command.
A “d” in the first slot means the file is a directory. Remember how, in the previous article, I said that directories are basically a special kind of file? This is another place where that knowledge comes in handy. It makes it easier to think of that first slot in the full directory listing as the “file type”.
Speaking of the file type, there’s one other special file type you’ll run into frequently (and some others you’ll see less frequently, but we’ll save those for the last article). You can see it here:
lrwxrwxrwx 1 root root 4 Jun 30 03:29 sh -> bash
The “l” (lowercase L) stands for “link”, and refers to something more properly called a “symlink”, sometimes called a “soft link”.
A symlink (as we shall refer to it henceforth) is a pointer to another location in the filesystem. You can see that over on the right - there’s a name (“sh”), followed by an arrow of sorts, and it ends with another name (“bash”). In this case, the link is named “sh” and it points to a file named “bash”. This means that if you call /bin/sh (in a script, for example), you will actually run /bin/bash.
A symlink doesn’t have to point to something in the same directory, either:
lrwxrwxrwx 1 root root 20 Jun 30 03:29 pgawk -> /usr/bin/pgawk-3.1.6 lrwxrwxrwx 1 root root 16 Jun 30 03:29 pidof -> ../sbin/killall5
In those examples you can see a symlink using an absolute path to reference its target, and another one using a relative path.
Briefly, to make your own symlink you can use “ln -s”, as in:
ln -s target link
That command would create a symlink named “link” that points to the file or directory named “target”.
Now we’re getting into the permissions. The next three letters in a file listing cover the “user” category of permissions. Consider:
drwxrwxr-x 2 root mail 4096 Dec 3 2009 mail
After the “d” that tells us that “www” is a directory, you’ll see “rwx”. These are abbreviations that hearken back to the types of permissions we can set:
r refers to the “read” permission
w refers to the “write” permission
x refers to the “execute” permission
So as you can see, the owner of the file (“user”) has all three permissions — read, write, and execute.
The next trio is also “rwx”. This triplet is for the “group” category, and the letters mean the same thing as they did for “user”. So for this directory, the group has as many permissions as the owner.
The last trio in this example is “r-x”. That set is for the final category, “other”, and in this case, “other” does not have write permission for the directory. So:
- refers to a lack of permission
Notice that there’s a specific order to the permissions in a triplet: read, then write, then execute. If there’s a dash in place of a letter for a permission slot, it means that category doesn’t have that permission.
To sum up what we have so far:
The first character in the directory listing refers to the file type.
The next three characters refer to the user permissions.
The next three characters refer to the group permissions.
The final three characters in that block refer to the other permissions.
After the permissions, there’s a number. Ignore it, it’s in the way. Someone else can tell you what that number means, it’s not important for this topic. Just move on. That number is dead to me.
Next you’ll see two names - in the above example, “root” and “mail”.
The first name is the name of the owner of the file. The “user” permissions will apply to that user when it attempts to access the directory, in this case the user “root”.
The second name is the file’s group. The “group” permissions will apply to any user (that is not the file owner) in the same group as the file. In this case, those permissions would apply to anyone in the “mail” group.
The rest of it will have to wait for another day, since we’re just looking at file types and permissions here. You can see a date, and there’s a column for size, but we won’t go into more detail than that.
Being able to check the permissions on a file is a good first step, and useful too. This is where troubleshooting can start — making sure a user can read a particular file, for example, or examining a directory structure to make sure users can work their way down the hierarchy to the files they need.
In the next article we’ll look at how to change the permissions on files and directories using the “chmod” command.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License