 So, as an example of access control, we will look at the Linux file system and how we can control which users can do what with different files. So, before we talk about that access control, we'll just explain what I mean by the Linux file system. Many of you have seen this in either my other courses or in my lab, but if not even if you haven't used Linux much, you'll be able to relate these concepts with what you've used in the past. We won't say what Linux is, we'll go direct to the file system. First, a Linux or a Unix-like operating system, including a Mac computer, has some file system which is organised in some hierarchy like most operating systems. We have a top level of the hierarchy and we refer to that as a root directory and under the root directory there are a number of sub-directories, so this picture just gives an example of some common directories or a common file system hierarchy. There's a root directory designated by a forward slash, under that there are sub-directories like slash bin, slash home, slash USR and so on. They have different purposes and it varies a bit across different operating systems and then maybe other sub-directories. For example, it's common that the users of the computer system will have their home directory in the directory called slash home followed by their username, so that's a common organisation. Bin usually is short for binaries, which is usually a place to store applications, so our computer system has applications and in a Unix or a Linux-based system that's usually stored in a slash bin directory, but there may be different locations for that. There's a slash bin, there's a slash USR bin. There may be differences in terms of maybe the core applications that come with the operating system are installed in slash bin, whereas other applications you install later may be installed in other sub-directories. You don't need to know the file system hierarchy, but when you do some of the tasks you may need to traverse it a little bit to move around. So we talk about directories and files, files stored within the directories. This is just some description of some of those sub-directories and there is some explanation of where applications are installed and some important ones for you. Maybe if you're looking for your home, then it's usually based in the slash home directory followed by a sub-directory with your username. Maybe you plug in a USB drive and it differs on some systems, but if you plug in a USB drive then usually there will be a sub-directory under slash media or a CD-ROM, so that's a common location. The operating system itself is usually configured by a set of text files which specify variables, the variables for the operating system and the common location for that is under the directory slash ETC or et cetera. If you're building a website on your Linux-based system then the location may be under RWWW. So these are just some examples of common directories you may see. So what we're going to focus on is, well, what do we mean by files and directories and then get to the file system access control? How do we implement an access control system on our file system? And the file system is organized with what's called inodes. The files and directories, the operating system keeps track of all the files and directories in things called inodes. An inode is a data structure, so I think it's a data structure that the operating system keeps track of and it stores some information about a file or a directory. We'll see in many cases we don't distinguish between a file or directory or that we treat them very similar from the file system perspective. So an inode will store, for a file or a directory, it will store the owner of that file or directory, so something about who owns this file or directory, the size. So if it's a file, it will store some information about how big that file is because we need to keep track of the size of files, that's a common thing. Time stamps, which may include many times, may include the time when this file was created, the time when this file was last accessed, someone looked at it and the time when this file was last modified, someone changed it. So there are three common time stamps which will be stored for each file, so that the operating system can report that information back to the users. An inode is a data structure that stores this information. The mode is really the access rights. So we talk about an access mode, we think of it as access rights. It says what particular users or classes of users can do with this file. That's what we mean by the mode here. We'll look at it in more depth soon. And of course, so this data structure stores this information about the file and then really has pointers to data blocks which contain the actual file or blocks of the file. So depending upon the size of the file, it may be split across multiple blocks on the hard disk. The inode really has pointers to those blocks. So when someone wants to read the file, they can find all the blocks of that file. So we think each file or directory, the directory is a little bit special, but each file at least has an inode associated with it which stores information about where the file is on the hard disk, who owns it, how big it is, what time it was created, modified and also the mode which is what others can do with this, what are the access rights. And what the operating system does is it maintains a list of inodes, I think one for each file in what's called the inode table. So the OS has some table which lists all the inodes. And when someone, a user wants to or a software process representing a user wants to access a file, then the operating system goes to its inode table and finds the inode information, checks maybe the permissions specified in the mode and then reads the file from the data blocks that it points to. Directories we think also as a file, but it's a file that lists the entries for each file in that directory. So think of a directory just as a file, but inside that file is information about the files which are within the directory, which includes the inode number of the file and also the length of the name of the file and the actual name of the file. So directories are treated as files as well, but they're a special type of file which says inside this directory there are these other files. And that is useful to be aware of because when it comes to permissions we usually have the same access modes on both files and directories. So this is about how an operating system stores information about files. And the reason we're introducing it is because we want to look at the mode or the permissions or the access rights in our file system. Do I have a picture? That's more detail about the actual inode contents. So the mode is 16 bits. The first 12 bits are what are called the protection bits or the permissions. Other things we're going to concentrate on. What people can do with this particular file. The other four bits indicate the file type. For example is this a regular file, a directory or something, some other type of special file. There's an owner ID, so there's a 16 bit value that specifies the owner of this file. There's a group ID which specifies what we say the group owner of the file. We can talk about that there's a user that owns a file and for that same file there's also a group that owns that file. There's a size entry which specifies the size in bytes and there's timestamps. Access time, change time. I know change so this is a bit confusing. Time when the data structure was changed and the time when the data inside the file was changed. We will usually just see when we see something about a timestamp for a file we'll usually just see the time when the file was changed, that's the main one we'll take notice of. An inode may have other fields but they're the main things of interest. There have been some extensions to add other information. Before we look at permissions, see if we can draw something just to illustrate what we mean by an inode and for files and directories. For example I think you've seen in some systems we may have a home directory and in there we may have a sub directory for a user and there that may have another sub directory and inside that sub directory maybe we have some files and a second file in the same directory called file2. Let's say we have two files they're both in the same sub directory ABC of my home directory. Then the operating system maintains an inode which is a data structure for each file and that inode would store the information, it will store the permissions more generally the mode, the owner information, the size and timestamps and it's points to where the file is stored on the hard disk. So it's a data structure, this is the inode includes what we say the mode, the size and other information and it includes pointers to say we have, how am I going to draw this, here's my hard disk. Then the inode points to different blocks on the hard disk saying that this file, file1.txt so think of this as a data structure that says this file that has some size, some mode, some owner and the file is actually stored on the hard disk in these locations and there will be an inode for file2 which would have the same information and say where it's stored on the hard disk, may be different location. Then depending upon the size of the file it may be stored across different blocks. So files store information, inode store information about files and where the files are actually on the disk and then directories. So the directory ABC, a directory is a file and that file lists the set of files inside that directory. So think of the directory ABC slash and inside that, how am I going to draw it, it's a list saying inside this directory is file1.txt and file2.txt and that would be useful when we look at permissions on directories. So a directory is really just a file but it's a special type of file. The contents of the file says something about the files inside that directory. There are two files inside our ABC directory so think of this on the file system as a file that says that the two files are file1 and file2.txt. It's useful to be aware about directories because we'll talk about permissions on directories and understanding them is easier if you understand how they are treated in the file system. So if you want to view the contents of a directory, the user wants to view the contents of a directory, what the file system actually does is it looks up, it finds where ABC is, there's an inode for ABC directory and then the file lists file1 and file2 and then the operating system will find file1 and file2 and find out the information about who owns them, what their size are and so on. So to read the contents of a directory, you actually read the special directory file. Questions? This is just setting the background a little bit for what we want to get to now, permissions. So the inode contains what we call the mode and the mode is split into two parts. The mode is 16 bits, the first 12 bits are protection bits and the next four bits indicate what type of file, is this a normal file or a directory or other special file. So we'll focus on the protection bits, the first 12 bits and in fact a subset of them. They actually specify the permissions or the access rights that users have on that file. Let's look at the access control of that file system. We talk generally about the permissions on either a file or a directory and the permissions that we have available are, or the access rights, if we talk about the terminology we used in the lecture, we said access rights but commonly just called permissions. The permissions are whether we can read a file, where read means see the contents, write to the file, modify the contents and execute the file. So run the program that's stored in that file. Any questions about the permissions on files? Read, write, execute. Any confusion about them? Maybe the only one people forget, what's delete? Is delete captured there? Can you delete a file? That's captured in write usually. If you can write to a file, you can delete the file. So think that write includes the ability to delete. If you can modify the contents then you can remove the entire contents. Now there are some exceptions or special cases when it comes to directories. So read, write, execute a file but we have also read, write, execute permissions on directories. So let's explain that. The read permission on a directory means you can see the contents of that directory. You can see what's inside it. Write permissions on a directory means you can create files in that directory and or remove files from that directory. So if I can write to a directory, I'm allowed to create a new file in that directory and I'm allowed to delete files from that directory. And execute permissions on a directory means we can access the files in the directory. So we still use read, write and execute but they have a slightly different meaning between files and directories. We also distinguish between types of users. So there's different categories of users. We talk all about the owner of the file. So again, coming back to the iNode, it specifies the owner information which is the user owner and the group owner. So we distinguish between different types of users. We can talk about the user, the one user that owns the file. There's one user on our system that owns that file. Then we can talk about the user in the file's group. So there's a group that owns the file. Any user inside that group has a certain set of permissions. And then there's the rest of the users. So with respect to one file, there's one user owner. There may be multiple users in the group owner and then there's the rest of the users on the computer system. And we'll often see abbreviations of U, G and O and another abbreviation we'll see is A means everyone. It includes those three sets of users. RWX, read, write, execute. U, G, O and A abbreviations we'll see in modifying permissions. The permissions that those three categories of users, user, group and others have are specified with a sequence of nine bits with respect to whether they have read, write or execute permission. So we have a combination of nine values. Can the user read, write or execute? So yes or no for each of them. Can the group read, write or execute that file? And can other users read, write or execute the file? So there are nine combinations there. So the file system stores nine bits. It'll be value zero if they cannot. Value one if they can do that operation. There's actually a few other bits which are used. Three more bits which are very special purposes which we're not going to talk about. So there are 12 protection bits. Only nine of them we're going to focus on now. The last three are for special cases. The first nine are of interest. And the way that we see it normally presented by the operating system is not as binary, the bits. It presents it as a set of letters to indicate which permissions we have. And I think many of you have seen it already. When you look at the contents of a directory or lists of some files, the operating system reports information such as what type of file it is and the permissions. And we'll go direct to an example to see that. We have a virtual node with a number of users. We've seen the users. Everyone has an account on this computer. We need to move it across a bit. And we have one user logged in. And let's just look at very simple examples of the permissions that he may have. An LS lists the file contents minus L to show the long output. Here's a file name. And the thing that we're looking at is these nine characters which tell us what. What can our user Nuttapong do with this file? He can read and write the file. So the way that we interpret these nine characters is that user that owns it is listed here. He's the user. And the permissions he has are read and write. He does not have the execute permission. The group that owns the file turns out to have the same name as the user, but it's a different entity, just the same name. And the permissions for that group are here. The next three characters, read, write, but not execute. And others, which are not the user and not in the group, read only permissions. They cannot write. We'll look at the directory in a moment. What can our second user do? Let's have a look. Let's change into the directory of our first user. We can change into another user's directory. It depends upon the initial permissions that are set, but in this case, we can. Cat just shows the output of a file, shows the contents of a file, which means if Cat will show us the contents of the file, it means we can read the file. Can our second user read the contents of our file? Yes or no? Why yes? Why? Why can they read the contents? So think carefully why they can. They can. No. The reason you know at this stage is that every user can read. The user can read. The group can read. Others can read. So all users can read because everyone's set to read. To be more precise, you should know whether our second user is in the group of that file. So we should really check the group. But in this case, the all users can read. So we know that we'll be able to read in this case. So we have a file. The user can read. How do we stop someone from not reading it? There are commands to change the permission. So this is discretionary access control. We can change the mode. Remember the mode is those permissions. Change the mode so the other users cannot read the file. Before we do that, can this user change the mode? Let's have a look. Let's say we want to allow us to read the file and then edit the file. If we delete something and try and save, we cannot save. We have permission denied. So we cannot modify the file because we are not in the group nut-a-pong. The group owner is nut-a-pong. Our user is not in that group and therefore is considered a other user and the other user only has read permissions. Can we change the mode so that we do have right permissions? The other user can only read. We want to give ourselves right permissions. Yes or no? Not permitted. So there's something else embedded in here that about who can change the permissions. Only the owner can change the permissions. You cannot change the permissions for other people's files. So if we want to remove the read permissions, then now we shouldn't be able to read the file. All right, so files. I think most people have seen this before with file permissions. That's not so bad. Sometimes you need to think about the cases and just check. Are you the user, the group or others? Let's look at directories then. Here's a directory. How do we know? The first character here is a D. This is a directory, Natapong's private directory. What can he do on the directory? Everything and what does everything mean? Read, write and execute. What does read mean? See the contents of the directory. Read, write means modify, think of create new files in the directory or remove files from the directory. How do we execute a directory? What's that mean? Meaning access the directory. Let's see that. Let's see what our malicious user can do. Can we change into the private directory? Can we change into the private directory? Yes or no? Why? So when we say when I ask why, think about, well what permissions apply for this current user? This current user is not the owner. We're not in the group. We saw the group before, so it's another user. With respect to the directory, the permissions, we have a read and execute. Change into a directory means the access to the directory. Yes, we can. So that's what access means. Execute, sorry. The x permission on a directory means we can CD into that directory. Let's go back. So what if Natapong wants to make that a private directory so that no one can see the contents in there? What can we do? We need to change the mode over others so that we cannot access that directory. Good. And go back to our user and see permission denied. We cannot access that directory. Can we see the contents? What happens here? Why can we see? So we cannot CD into the directory, but we can list the contents because we have read permissions on that directory. So our other user has read-only permissions on the directory so we can say that we can see what's inside it, but we cannot change into it. Okay, so you need to be careful with directories, especially if someone wants to keep a directory private. In this case, we cannot CD into it, but we can at least see the file names and that may be revealing something secret in itself. Can we see the contents of those files? They want to be private. We cannot access the contents of this directory. Let's see another thing. So we can just see the file names. So the execute means we cannot do anything internal inside that directory. We can see the file names because all the directory is a file in itself. A directory is a file. I tried to illustrate that here. The directory ABC is just a special file that lists the names of other files. So when we have read permissions on the directory, it means we can see inside here. We can see that inside this directory is file one and file two. But when we don't have execute permissions, we cannot see anything about those files other than their names. So we cannot see the details of them, including read those files. So that's why when we try to LS, we know that there are two files there, but I know nothing about them. What if we, as the user, we tried to set the permissions to be slightly different? So here we only have execute permissions on that directory for the other users. We don't have read permissions. What can our other user do? What can our other user do? Can we see the contents? Permission denied. So we cannot list the contents. But we can guess what files are in there. Maybe we could. Maybe we saw before we knew what files. Do you think we can see the contents of the files? Why? So we can access the directory and then it depends upon the permissions on those files. So we can see the contents of the files. So stop blocking. Read permissions on the directory is not enough to block someone reading the contents of that directory. So on directories, you need to be careful. If you want to set up for some level of security or confidentiality of your files in a directory, you need to be careful between read and execute permissions. Sometimes to be secure, you'd like to remove both of those permissions, read and execute. So no one can see the files inside there and no one can access the directory and see the contents of the files inside the directory. We can still cd into this directory. But we cannot see the contents. That is the list of files. But if we know the files there, we can still read them because we'll go back to our first user. The files have read permissions for other users. So just blocking access to read permissions on a directory doesn't necessarily stop people from reading the files in that directory. So it gets a little bit confusing there. Questions on that? Questions. Because this is your homework. When we remove the read permissions, what have we got? We cannot see what's inside this directory because we only have execute permissions on the directory. The other way, you mean? Okay, the question is what if we have, I think, the opposite here? We have read permissions but not execute permissions. Correct? Is that the question? This is the example we had before. We can see the files inside the directory but we cannot do anything with those files because we cannot access that directory. We don't have execute permissions. So we've tried two cases. Read only, execute only. Of course, we can have no permissions and then you'll find you can't do anything. You cannot read or execute. If you have read and execute, then you can CD into there and see the files inside there. Write adds more confusion. The write permission can add more complexity in terms of what you can delete and what you cannot delete. But we'll leave it at that point. So to finish here, I think you've seen some of the commands, LS especially, and there's a few other commands which you'll learn in the homework but some you may not have heard of. Stat shows us the details of the file and there's some others there. Change mode. And to get more details, you can list the attributes, change the attributes. So have a look at your homework which requires you to do some very basic setting up of permissions. So given some requirements, set the mode, set the permissions.