OPS145 Lab 4 Newversion

Binary review

Go back and review the binary stuff we looked at in the course introduction.

This lab is about POSIX permissions, and you need to be completely comfortable with binary-to-decimal and decimal-to-binary conversion from 000 to 111 (decimal 0 to 7).

Here's a summary of the absolute minimum you need to remember from that:

Binary	Decimal
000	0+0+0=0
001	0+0+1=1
010	0+2+0=2
011	0+2+1=3
100	4+0+0=4
101	4+0+1=5
110	4+2+0=6
111	4+2+1=7

Read, Write, Execute (rwx) permissions

On a Linux filesystem every file and directory has 9 bits of information allocated for reording basic permissions. Those 9 bits are split into three groups of 3 bits.

Each group of 3 bits records whether the following permissions are granted:

• read permission (most significant bit, on the left, decimal 4)
• write permission (second bit, in the middle, decimal 2)
• execute permission (least significant bit, on the right, decimal 1)

These are usually called "octal" rather than decimal, but I suspect you won't find any value in that extra complication, so you can just think of them as decimal numbers.

Permissions for files

The read and write permissions for files are pretty self-explanatory:

• If you have read permission for a file: the operating system kernel will allow you to read the contents of that file.
• If you have write permission for a file: the OS kernel will allow you to make changes to the contents of that file.

No permission implies any other permission. For example having write permission does not imply you have read permission, even though you might feel that you should.

The execute permission is more complicated.

Remember that on Linux file extensions don't make much difference. In Windows the operating system will attempt to execute anything with an .exe extension that you double-click on. Linux will refuse to execute any file which doesn't have execute permission.

On the surface it seems simple. You either are are are not allowed to execute a file. But the complications are in the details. What exactly does it mean to "execute" a file? Different people will have different answers to that question.

The easiest way to think about the execute permission on a file is as a hint: if this file has execute permissions: it is a program that's intended to be executed. If it doesn't have execute permissions: you are not meant to try to execute it, though if you really wanted to: you probably could figure out how to do it.

The read and write permissions are used to secure access to files. The execute permission is just a convenience.

Permissions for directories

Read, write, and execute permissions on directories are intuitive for some people, but for everyone they will make more sense if they begin their understanding by thinking of the concept of a file/directory on a filesystem.

Remember that there's a difference between the file's records (e.g. name, size, modification date, permissions) and the file's actual contents.

• For a file: its the contents are the bytes representing the text, image, or whatever data is in the file.
• For a directory: its contents are the records of the files/directories contained inside that directory. Not the contents of those files/directories, but only their records.

With that in mind:

• If you have the read permission on a directory: you will be allowed to read its contents, meaning: see what's inside the directory.
• If you have the write permission on a directory: you will be allowed to modify its contents, for example by copying a file into that directory, or deleting a file from that directory, or renaming a file in that directory.

As with files, the execute permission for directories is more complicated.

In most cases this is the simplest way to think of execute permissions:

• If you give a directory read or write permissions: give it execute permissions too.
• If you give a directory only execute permissions: you won't be able to read that directory's contents but can "get to" the directory's contents. For example:
  • Open a file in that directory if you already know that file's name,
  • Cd to a directory inside this directory, if you already know that directory's name

File ownership; user, group, others

On a POSIX filesystem each file record specifies a user who is the owner of that file, and a group who is the owner of that file.

The user who creates a file is automatically the owner of that file.

That user will be a member of a group, and by default the group owner of the created file will be that group.

Only the system administrator can change the owner of a file. The owner of the file can only change the group owner of a file if they are a member of the new group.

From an ownership/permissions point of view: if someone is not the owner, and they're not part of the group owner: they are classed as "others".

Putting it all together

Each file/directory record on your filesystem has 9 permission bits. The permission bits are shown when you run ls -l, but instead of showing 1s and 0s it shows the meaning of those bits:

• r for read, w for write, and x for execute if that permission is granted
• - if that permission is denied

Permissions for files

Permissions for directories

Examples

• Download this tarball for practice in this lab SamplePermissions.tar.xz and extract it into your downloads directory so that you'll end up with a ~/Downloads/SamplePermissions directory.
• Create another user on your workstation. The extra user will also help with the practice:

  sudo adduser joe --uid 1145
  # put in your own password at the sudo prompt
  # put in any password you like for the new user joe
  

• In a terminal change to that directory, and run ls -l

• Ignore for now the first character in the ls -l output, it has nothing to do with permissions.

• Here are examples of ways to check whether permissions set on these files work:
  • Run cat <nameofthefile> to read its contents
  • Open the text file in a graphical text editor, make some changes, and attempt to save your changes.
  • Run ./<nameofthescript>.sh to attempt to execute that script.
  • Run mv <originalnameoffile> <newnameoffile> to attempt to rename
• Answer the following questions first, and then check whether you were correct.
  1. Which of the files can you read?
  2. Which of the files can you change the contents of?
  3. If you are unable to change the contents of a file, can you still rename that file? Does that change its permissions?
  4. Which of the files can you execute?
  5. Which subdirectories can you cd into?
  6. Which subdirectories can you see the contents of?
  7. Both the NotAllowed and SortOfAllowed directories contain a file called ForThoseWhoKnow.txt - can you read its contents?
• Open a second terminal window, and switch to the joe user in that terminal using the su command:

  su joe
  

  In that one window you are not your regular user, you are joe and you only have the privileges that joe has.
• As joe, change to the JoePractice directory. Answer the following questions first, and then check whether you were correct.
  1. Who owns all the contents of this directory?
  2. Which of the files can you read? Which of the files can Joe read?
  3. Are there any files joe can read but you cannot?

You are the owner of the files, and joe (not being part of your group) has the permission of others.

Changing permissions with chmod

Once you understand how permissions work: you can start changing them to accomplish security goals. The POSIX permissions system is relatively simple, but it can still be used on its own to secure files on a server which is accessed by many people.