Welcome!

Linux Authors: Toddy Mladenov, Maureen O'Gara, RealWire News Distribution, Gathering Clouds

Blog Feed Post

Unix File Permissions

Typically, one of the early things a new user on a Unix-like system will encounter is the need to understand the *nix file permissions system.

This usually arises from some need;

this process won't start because it can't read xx file
  or perhaps seeing
gpg: WARNING: unsafe enclosing directory ownership on configuration file '/home/user/.gnupg/gpg.conf'
 when trying to set up encrypted file and mail capabilities.

Basic Mechanics of the Unix File Permissions

So let’s cover the basic mechanics of *nix file permissions for Unix/Linux. If you have some files in a directory, you can do

ls -ltrh
to see the files listed in detail. This command shows:

-l use a long listing format
-t sort by modification time, newest first
-r –reverse – reverse order while sorting
-h –human-readable – with -l, print sizes in human readable format (e.g., 1K, 234M, 5G)

This will list your files in a detailed fashion, with the last-modified file at the bottom of the list. (Remove the ‘r’ to disable this and have the oldest file at the bottom.)

So let’s start with a file in a directory:

~/files $> ls -ltrh
total 40K
-rwxr-xr-x 1 user user 38K Jan 21 23:52 filename.txt
~/files $>

In this example we see that there is a file called “filename.txt” in this directory. The first section of the entry: -rwxr-xr-x is the description of the file permissions that are active. This entry consists of ten places, or bits, which tell the system what users and the system itself can or cannot do to this file. Let’s review what each of these bits means.

Unix File System – Bit Meanings

The ten place bits in a unix file permission entry are laid out like so:

1
= entry-type bit (what sort of thing the object is- i.e., a file, a directory, etc.)
2-10
= permissions  (what the system and/or users can do to the file.)

The entry-type bit can be:

-
  = Regular file. (the most common for general ‘user’ operations)
b
= Block special file (stored in /dev).
c
= Character special file (stored in /dev).
d
= Directory.
l
= Symbolic link.
p
= FIFO (named pipe)
s
= Socket.
w
= Whiteout.

Unix file permission entries are broken into three groups of three bits:

2-4
 : owner’s permissions
5-7
 : group’s permissions
8-10
: other’s permissions

Permissions entries can be:

r
: The file is readable; if it’s a
-
it is not readable.
w
: the file is writable; if it’s a
-
, it is not writable.
S
: If in the owner permissions, the file is not executable and set-user-ID mode is set. If in the group permissions, the file is not executable and set-group-ID mode is set.
s
: If in the owner permissions, the file is executable and set-user-ID mode is set. If in the group permissions, the file is executable and set group-ID mode is set.
x
: The file is executable or the directory is searchable.
-
: The file is neither readable, writable, executable, nor set-user-ID, nor set-group-ID mode, nor sticky.
AND FOR THE LAST BIT OF OTHER (
10
), it can also be one of these two values:
T
: The sticky bit is set (
mode 1000
), but does not include execute or search permissions.
t
: The sticky bit is set (
mode 1000
), and is searchable or executable.

Further explanation of the sticky bit: The sticky bit is often used on folders to prevent the deletion of a folder or its contents by other users, even though they may need to have write permissions. Once it is set on a folder, it can then only be deleted by its owner or by root. So users would still be able to modify or work on those files, but not delete them or the parent folder. This is a useful tool to preserve your file structure on a multi-user system.

Expanding On the List Command

So, let’s look back at our example, but let’s also expand it a bit:

~/files $> ls -ltrha
total 48K
drwxr-xr-x 67 user user 4.0K Jan 21 23:51 ..
drwxrwxr-x  2 user user 4.0K Jan 21 23:51 .
-rwxr-xr-x  1 user user  38K Jan 21 23:52 filename.txt
~/files $>

You’ll see the ‘a’ switch added to the end of the command there. This tells the ‘list’ command to show even hidden entries, which in this case are the *nix “this directory” and “parent directory” dot-entries. You’ll see on

filename.txt
the permissions:
-rwxr-xr-x
. This means that:

  • The first bit is a dash. This is a regular file.
  • The owner permissions bits are: read, write, execute. The owner can basically do anything to this file.
  • The group permissions bits are: read and execute. Members of the same group can read this file, and execute it if it’s a program. They cannot write to it, so cannot change its contents.
  • The other permissions bits are: read and execute. Others (users in different groups, daemons, etc.) can read it and also execute it. They cannot write to it, so cannot change its contents. 5. Owner and group are both “user”
  • The size is 38 kilobytes.


Directory Permissions

This expanded example also shows us an important feature of *nix permissions as related to directories. You see the two entries there,

.
and
..
. These refer to “this directory” and “parent directory”, respectively. What we want to note is that in their permissions entries, the first character is a
d
. This denotes, of course, ‘directory’. Note however that when a directory has an
x
anywhere in its permissions settings that translates to “can read the contents of this folder”.

For instance:

~ $> chmod 300 files/
~ $> ls files/
ls: cannot open directory files/: Permission denied
~ $>

What I did here was set the folder permissions to take away execute from all parties. Then, when the owner tried to list the contents of the directory he received a permissions error. However:

~ $> cat files/filename.txt

This command still works, since the permissions on a file within the directory are still

-rwxr-xr-x
.

Applying More Restrictions With chmod

Now, if we wanted to change the file permissions to be more restrictive, perhaps to disallow anyone but the owner from reading or executing the file, we would have to change those bits to different values. This is accomplished with the ‘chmod’ tool. It “changes mode” on the file, telling the system how to treat the object. To tell the system whether we want read, write, execute, or some combination of the three, we need to know how ‘chmod’ describes these modes in relation to User, Group, and Other.

There are seven chmod Mode Set characters:

1
= execute
2
= write
3
= execute+write (2 + 1)
4
= read
5
= read+execute  (4 + 1)
6
= read+write    (4 + 2)
7
= read+write+execute (4 + 2 + 1)

This means that to set permissions with the chmod tool, you would do something like:

chmod 700 filename.txt

This will set owner as read+write+execute, and set group and other both as ‘none’. Then,

ls -ltrh
again will show the new file permissions:

~/files $> chmod 700 filename.txt
~/files $> ls -ltrh
total 40K
-rwx------ 1 user user 38K Jan 21 23:52 filename.txt
~/files $>

This example shows: The first bit as a dash

-
this means that the entry is a regular file. The next three bits are
rwx
this means that owner has read+write+execute. The next three bits are
---
this means that the group has NO read, NO write, and NO execute. The last three bits are
---
this means that all others have NO read, NO write, and NO execute.

To demonstrate how this works, try taking away the owner’s “read” permissions:

~/files $> chmod 300 filename.txt
~/files $> cat filename.txt cat: filename.txt: Permission denied
~/files $>

What we just did was give the owner write+execute-only permissions. So the owner could still modify and execute the file, but could not read it. Thus, the

cat
command failed. For the owner, since ‘write’ permissions were still in place, he could then reapply his read permissions to gain access to the file contents. If a user inadvertently removed his read, write and execute permissions on a file, he’d either have to have root access or have an administrator reapply the proper file permissions.

Final Notes on Unix File Permissions

So with this basic understanding of Unix/Linux file permissions, you’ll be able to relatively easily manage what can be done to files on your system. This can aid in protecting configuration files, preventing sensitive information from being compromised, or simply be used as a safety check to keep yourself from deleting an important item.

Just remember- make sure you actually understand the chmod you’re about to do before you hit enter, or you may end up needing some root-level rescue.

The post Unix File Permissions appeared first on Hurricane Labs.

Read the original blog entry...

More Stories By Hurricane Labs

Christina O’Neill has been working in the information security field for 3 years. She is a board member for the Northern Ohio InfraGard Members Alliance and a committee member for the Information Security Summit, a conference held once a year for information security and physical security professionals.