 And we'll use Linux as the example. And you'll have a small homework task. The next one will be setting permissions on users to achieve some goal, not too hard. Everyone uses Linux. Yes, if you've taken my lab, if not, you'll learn it very quickly. So to understand about, we're going to look at an example of discretionary access control. We need to know something about the Linux operating system and how it implements permissions. So these are some extra slides about Linux, about the file system. That is how we arrange the files, the directories and files. We're not going to go through all of those slides. We'll go direct to the thing about permissions. So in Linux, we talk about files and directories. What's a directory? A folder with respect to the right? We know what files are. So we have some area of storage on the disk that saves some information. But what's a directory? Well, one thing we can think of a directory. A directory keeps track of a set of files. It's some grouping of files. Inside this directory, there are some other files. So in Linux, we think of a directory is in fact a file that lists other files. If we go into a directory and we LS in that directory, we can see a set of other files. So for storage, we'll often think of a directory as a special type of file. There's like a list of other files, the file names in that directory. So we need to understand a little bit about the organization. The hierarchy of the directories is not important at this stage. But the files on your hard disk are organized in some manner. And there's different ways to store information about those files. And that's done by a file system. So the software for a file system keeps track of all your files and directories. There are different ways to do it. But we'll go through it a simple example and we'll refer to inodes. In Linux file systems and other file systems, files and directories are kept track by the operating system using inodes. Inodes are small data structures that keep track of some information about the file. You can think the file just occupies some blocks on disk, some areas on disk. But the inodes keep track of things like the file name, when that file was created and accessed, where it is, and the permissions for that file. So an inode in Linux is a data structure, stores information about a file or directory. It stores information about who's the owner of the file, how big it is, how many bytes, some timestamps. Timestamps can include when was it created, when was it last accessed. So we may create a file this time and then access it another time. We may keep track of both times. And where is the data for that file stored? So we think an inode is a small data structure and it points to the actual file, the data blocks on the disk. And the other thing it keeps track of is the mode in which that file can be accessed, the permissions. So what your operating system does is it has a list of inodes, one for each file. So it has a table, special area in the operating system that keeps track of the inodes, where each inode keeps track of some information about files and directories. Directories are files, but they're a special type. What a directory is, it's a file that points to other files and it points to the other files in that directory. So it points, keeps track of in this directory, if there are three files in that directory, then that with respect to the operating system, the inode keeps track of what are those three files, what are the inodes of those three files, how long the file names are and what are the file names. So because we say directories are a special case of files, they can also have permissions on them. Directories can have permissions. So we said the inode is a data structure that keeps track of information about files. This is the general information. More detail. We'll skip mode, we'll come back to that. There's the owner ID in Linux. There's a 16-bit user ID. Who is the owner of this file? There's one owner of every file. And there's one group associated with every file. So there's also a group ID. The size of the file in bytes is recorded. So this data structure records the file size. There are several timestamps. The node is A time, C time, M time. When that inode was accessed, when someone read the file last, when it was changed, when it was something was modified, and when the file data was modified. So the inode may be modified, but the file data not. For example, if we change permissions, the data structure changes, but the file contents do not. And at the start, we have 16 bits in this inode, in this data structure, that what we call the mode, the mode of the file. 12 bits are called the protection bits, which we will describe as the permissions on that file. And four bits determine the file type. So is it a regular file? Is it a directory? Or there are even some other special cases. So we can think every file has its own inode and stores this information. There are some other fields as well. So in more advanced cases, there are some other information. Let's have a look with an example. Here's our users logged in on our computer. We currently don't have any files. Let's create a file. We now have a file. We can see some information about the inode of that file using the command stat. Stat on that file shows us some details about that file. It shows us the file size, blocks. So this is something about the blocks on the disk. So different file systems may manage the disk blocks in different ways. It's a regular file. The inode is the data structure that keeps this information. And inodes have IDs or numbers. And this is inode number 156. So another file would have a different inode number. The inodes are just data structures that store this information. The user ID and user IDs are 16-bit numbers. But we often also have a mapping to a name. So there are actually numbers, but we usually convert that to a name. A group ID, so every file has a user owner and a group owner. The three different timestamps. When was this inode accessed? When was this inode modified? When was the file changed? So we keep track of three different values. And the other thing that we wanna focus on is the access control. These are the owners. What can the user do with this? The mode for the file. And these are what we call the 12 protection bits. Keep track of this information. It's stored in 12 bits, but those bits have meaning, so we'll interpret them. So that's an example of the inode information for file. We commonly look at details for a file using LS. And we see some of that in maybe a slightly easier form. The file name, the size, the time when the file was last modified, the user, the group, something about the mode. What's this number one mean? What's the number one mean? You've seen it many times. Something we probably haven't explained before. It's actually, it's to do with the number of links to this file. So I think you know most systems we can have shortcuts or links to files. So in a Linux system, other files can link to this one. And other inodes can link to this one. So we actually store the file once, but we have other inodes that point to this one. This is the number that link into this file. Usually we see it's one. Only in some special cases we'll see it's different than one. So we often ignore this number because we don't often see it change in our simple cases. So we wanna look at what do these, what are the access mode? What do these characters mean? What's this character mean? You all know this or most of you know this. The first dash, it means this is a file, not a directory. If it was a D, it's a directory. If it's a dash, it's a regular file, all right? So it's a regular file. It's just shorthand to say this is a regular file. Wrong way. It's the file type, all right? We actually have four bits to indicate the file type, but we'll commonly see either a regular file, a dash there, a directory. Maybe we'll see some others later. And then these are the next nine characters we're gonna look at. There are nine characters there. They're either set or unset. Each character actually is implemented as a single bit, on or off. So we just need to understand what the meaning of each character is or what each bit is. And I think most of you know that the sequence determines the access mode or the permissions on that file. Whether we can read, write, or execute that file from the perspective of the user that owns, the group that owns, and others. So we'll look at that in a bit more depth. So we just implement that by a single bit. If it's zero, we cannot. If it's one, we can. Or here the operating system shows the letter if we can or a dash if we cannot. So let's look at those bits. Here we say there are actually 12 permission bits or protection bits. We see nine there. There are nine characters. There are another three special cases. So there are 12 bits that determine the permissions on that file. We will look at the nine main ones, but there are some special cases as well. So with Linux, we talk about the access rights or the permissions being read, write, or execute. Read a file, you can see the contents. Write, you can modify the contents. Execute, you can run it. Especially if we have a script or a binary program, we can execute that file. What about a directory? Because directories are also special types of files. So they can also have permissions. What do they mean? We can read. If a directory has the read permission, it means we can see the contents of that directory. What files are inside that directory? Because a directory is just a file that lists the files inside it. If we can write, we can create and remove files from that directory. So if we can write to a directory, I can put a new file inside that directory, and I can delete a file from that directory. Execute a directory, that doesn't make sense. We can execute files, programs, but what the execute permission means, we use the same character, it means we can access files in the directory. And one thing you understand, we can change into that directory. We can CD into that directory as an example. We categorize users, we talk about the user that owns the file. There's a group that owns the file, and there may be users in that group. And then there's other users. So we can say there's one user that owns a file, there's a group of users for that file, and then there's the rest of the world, others. And we'll often use the letters U, G and O to refer to them. Or we can talk about all users on the system, hey. We said there were nine bits, sorry, 12 bits for protection. Well, read, write and execute for the user. There are three bits. Read, write and execute for the group, another three, and read, write and execute for others. So there's nine bits. Then there is three special cases. Set UID, set GID sticky bit. Remember them? Everyone have any questions? Anyone questions about the special bits? You probably haven't seen them in use. So we've seen the first nine bits in use in a lab. We haven't seen these special commissions in use. They're used to control some very special cases which I think we'll not demonstrate. And sometimes they're no longer used. That is, they had an original use, but no longer used for that purpose. One thing that they're still used for, for example, directories, this set UID bit, if we, so it's a bit, it's either on or off. If we set it on, it means that the files created in that directory are given the same user as the owner of the directory. So someone owns the directory, if a file is created inside that directory, the owner of that file is the one that owns the directory. It may not be the case if we set that to be off. So that's one thing that's used for. Similar with the group, the owner and the group. And one thing, the third bit that's called the sticky bit sometimes is used for is preventing users from removing or renaming files in a directory unless they are the owner. That is, in some cases, someone else's file is in your directory and you can delete their file. By using the sticky bit, you can control that such that you cannot delete their file. But if you don't remember those three, you'll be okay. Remember the first nine combinations. And this summarizes how we interpret it. Even though there are 12 bits in Linux, we commonly use the LS command to see the values of nine of those bits. These nine characters here. Whether the user can read, write, or execute. Whether the group can read, write, or execute. And whether others can read, write, or execute. In this example, the user can read and write. The group can read. They cannot do other things. So let's go back to our system and see some simple examples. We have three users here. The yellow, the red, and the green. We have three users logged in. And we're gonna operate on the first user's files. So they're all in the first user's directory. What can our red user do on this file? File one dot txt. What can the red user do with the file one dot txt? Why can they read it? Well, we need to look at the permissions on that file. These nine bits. These three bits tell us what the user owner can do. Who is the user owner? Listed here in the first column. These three bits tell us what the group owner can do. Who is the group in the second column? And these three bits tell us what others can do. What is our red user? User, group, or others with respect to file one. Our red user is a user owner, group owner, or others. How do you know others? Well, we need to actually check. We need to know who is in this group. So the groups, I think you'd guess that there's only one person in this group, but what we should do is check who is in this particular group, because a group can contain multiple users. So to determine what our red user can do, we need to know, well, they're not the user that owns the file, that's shown there. Are they in the group? If not, they are others. Well, what groups are we in? Well, no, we're not in this group, so you're correct. They are the other user with respect to that file. And the other user can only read the file. So we can see the contents of the file. Can we add something to the end? Echoes some extra text to the end of that file? Permission denied. Adding to the end is editing the file or writing the file. So we cannot write to the file as another user, but we can read the file. So what I tried to do is echo some text and this redirect appends to the file. So I tried to edit the file. It says no permission denied. Okay, this one's the simple cases. Let's change the group owner. How do we change a group owner? What groups are there? What groups are we in? Well, I've set it up so all of our users here are also in the students group. All right, they're in their own named group plus in the students, the common students group. So let's change the group of this file to be students. Change the group of file one.txt to be students. What can our red user do now? Can we add to the end? Yes, we can. We're now in the file is owned by the students group. Our red user is in the students group. Therefore they have the permissions of read and write on the file. So they can modify the file now. And when I did the echo to append to the file, it worked, it didn't say permission denied. And now they've added to the file. So this allows multiple users to edit the file. What about directories? Many of you have played with permissions in a lab or if not you'll play in the next homework and you'll set some permissions. So you'll quickly learn how the roles of read, write and execute work for user group and others. And they're not so hard once you know the syntax. You can change the permissions. We can change the ownership, change group. We can also change the mode of the file, file one, the access mode listed here. Let's clear and show that again. We can change the mode so that the group cannot write. Change the mode of the file so that the group cannot write. And now the write permission is removed and we're permission denied. So our red user who's in the students group can no longer write to the file because we removed the write permission for the students group. What about directories? Let's make a directory and let's go into that directory and make a file. So here we have a file in our directory, mystuff. I want it from the user's perspective to be secret. It's got my password in it. Let's try and control who can access the directory. Not the individual file because maybe I have some other files in here. Maybe I have another file. So I have multiple files in there. I don't want to set just the permissions for the files. Maybe I want to control who can access the directory. So let's see how permissions work on directories which are sometimes a little bit less obvious. So the mystuff directory is a directory because we see a D at the start, not a regular file. The user can read, write and execute. The group can read, write and execute. Others can read and execute. Our red user, what can they do with respect to the directory in mystuff? Our red user, and again, we've gone back to the individual group. So our red user is others with respect to this directory. What can they do? What can the red user do on the directory? They are others. Other permissions on the directory, read and execute. What does read mean? What does execute mean with respect to a directory? Well, let's see what we can do. Can we see the contents of the directory? Yes or no? All right, we can see the files in the directory. Can we change into the directory? Yes, we can and still do an LS, do an LS minus L. We can still see the files, can we read the files? Yes, the permissions on the files are still readable by others. So there's no control yet with respect to our red user on that directory. Let's change the permissions on the directory and see how they impact on the controls. Let's go back. Let's remove the read permissions on the mystuff directory. What's going to happen? So now our other user doesn't have the read permissions on the directory. What is a directory? A directory is a file that lists the files inside that directory. If we cannot read that special file, we cannot read the list of files inside that directory. So here it says permission denied. We cannot see what's inside that directory. So this is the impact of the R permission on a directory. Can we change into the directory? Yes, execute is the ability really to change into a directory, to access a directory. Can we do an LS? No. So we can change into the directory, but we can't see what's inside it. The read is what's inside it. The execute means whether we can access that. So that's a little bit different with respect to files. What about the secret? Can I see it? I don't know what files are there, but if I could guess the file, if I knew maybe there was a file. So even though I cannot list the files inside this directory, if I could guess the file name and that file was unprotected, that is it still had read permissions, I can still see the contents of that file. So this read permission on a directory just means you can't see the list of files in there. It doesn't mean you can't access those files or you can't CD into the directory. So it doesn't really provide security measure on that directory. If we could guess the file name, we can still see the contents of that file. Let's go back. Let's add the read permission back and remove the execute permission. So now the other can read the directory but not execute. What happens here? I try to list the contents of that file, of that directory. It actually shows me the two files in there. So I can see the contents of the directory. There are two files in there. I know their file names, but this LS returns some errors, because when you do LS, what LS does is shows me the contents of the directory and often also shows, tries to access the files in there, but it cannot access them. And that's clear when we try to CD. We cannot change into my stuff now. Execute on a directory means you can't change into that directory. What LS does, it not just lists the contents of the directory but tries to access that directory to see the files. So we know there's two files in there but I cannot CD into that directory. Can I see one of the files? I know the name. Is it gonna show me the password or not? Permission denied. Because what I need to do from an implementation perspective, I need to really CD into my stuff and then look at secret.txt. So I know that there's a file in there and actually we know that it's readable but because we don't have execute permissions on the directory, we cannot get into that directory to access the file. So this is the X permission on a directory. Right, it's a little bit more obvious. Let's change it back and also add the right permission on the directory. Sorry, what's the permissions of? So now others can read, write and execute that directory. So our red user can CD into there, LS and our other user can create files in this directory. So this is the right permission. Now others can write to this directory. So we can create a file. Note that that that new file created in this directory is owned by our red user. We will not show it, but the sticky bit, sorry, the set GID bit, where was it? In one of the special bits, the set UID bit for the user, files created in that directory, if we set that special permission, the file created would be given the directory user's name, not the user who created the file. So we can change who owns the files in someone else's directory. So that's a little bit about permissions with respect to directory. So I think if you haven't had practice with files, then you will in the homework. So it's best to practice. Last thing to demonstrate, we've got our three users. They're all in the students group. What if we want to have finer grain control and allow, say, a particular user to access to write to our file one? So sometimes we'd like to, even if we have many students in the group, we want to say just two or three people can write to a file. So currently in Linux, the way to do that is to create groups. But it gets quite complex if you want to have maybe not just a group of students, but a group of your friends to access a file. So there's an extra form of permissions which is used as an access control list that allows us to give finer grain permissions. And I'll just show an example of that. We need a different command. Currently, our two users cannot edit the file. We cannot edit the file. We cannot echo into the file and append to it. We don't have permissions to write to the file. There are some other commands. We can set the file access control list. So there's a separate access control list that we can add finer grain control. Set the file access control list. Modify it so that a user with a particular name can write to a file. Now, who can edit this file? Our red user still cannot. Our green user can. So this is finer grain permissions where we can set for a particular user what they can do, irrespective of groups and others. So this is a little bit more advanced. We will not see many examples of that, but it's much more powerful because what we do is we set a particular file access control list. We can see that to finish. This file, the user can read and write. The group can read. Others can read. The mask is used for default permissions. So if we create a new file, the mask is commonly used to set what are the initial permissions? And here what we did is we said this specific user can also write to the file. So this is something we can extend upon the normal permissions in Linux to allow control for individual users. And that's a much more powerful discretionary access control so we can give permissions to any particular user. So you'll have a homework task where I'll say here are some conditions or some users create some users, create some files. And here's the policy we want to implement. Here's our goals. You use these commands to implement those policies. That will give you practice with Linux permissions and access control.