Now that we have an understanding of the different flags we can use when it comes to opening a file in Go, in this lesson we're going to take a look at the other side of the equation, which is the files mode, also known as file permissions. In this lesson we're mainly going to focus around Unix file permissions, as Windows has a very different concept known as the ACL.

If you want to know more about Windows and you've purchased this course, then let me know on Discord or send me an email, you can find a link on the contact section of the website, and I'll do a dedicated video on it. However, be advised, Windows permissions are a lot more complex than say using Unix. However, if you want to get up and running with Windows ACLs, I recommend taking a look at the Go ACL package, which provides a package for manipulating ACLs or access control lists on Windows. And as it mentions, it is pretty difficult to do, but this package simplifies the process.

In any case, as I mentioned, we're going to be talking more about Unix systems, so Linux and macOS, FreeBSD, etc, etc, where file permissions are a little bit easier to understand, although they can be daunting at first. In order to understand what file permissions are, we're going to be looking both at the terminal, and how we can manipulate permissions within the terminal, and their counterpart functions when it comes to the OS package.

If you'll recall, back in the last lesson, we took a look at the various different flags we can use to control the behaviour of an opened file, whether it was creating it if it didn't exist, opening it in read-write mode, read-mode or write-mode, or the ability to trunk or append to the file. To achieve this, we made use of the OpenFile function, and we used a BitwiseOr when it came to passing in the flags we wanted to define. The third argument, or third parameter to this function, is the actual files mode, or file permissions.

If we take a quick look at the documentation, you can see that the permissions, or file mode, is the final argument. And the documentation mentions that if the file does not exist, and the OCreate flag is passed, then this file will be created with the mode permissions. Then, if successful, methods on the return file can be used for IO. Therefore, in simple terms, this means that the permissions will only be applied if the file is created. And if we want to change the permissions of an existing file, we actually need to use some other methods, such as the changeMod function found in the OS package. Again, we'll talk about that more in a minute.

For the meantime, let's actually talk about file permissions in Unix, and how they work. In order to understand file permissions, we first need to understand the concept of ownership of files in Unix systems. In Unix system, every file has an owner, which, when I run the ls -lah command, you can see is presented in the third column. The first column is actually the file mode, or the permissions that have been set. The second column is the number of links that the file has, so any symbolic links. Don't worry too much about that for this lesson.

The third column is the file's owner. This is the name of the user that owns this file. A file can only have one owner. If we take a look at the / directory, you can see that all of the files and directories in this directory are owned by the root user. As I mentioned, each file can only have one owner, but they technically have two types of owners. The first is the user that owns the file. In this case, it's my Eliot user, which is the main user that I use. However, the next column defines a group that owns this file, or a files group. This is actually a second permission that we can define on this file, and we'll take a look at that shortly. However, this is a separate group that doesn't necessarily own the file, but they can have elevated permissions compared to everyone else, which is actually what the third permission defines.

So with that understanding, we can now take a look at how permissions work a little more. As you can see, the permissions are defined on the first column of the ls -la command. And as I mentioned, there's actually three different permissions that can be applied to a file. When it comes to Unix, the actual first dash or d defines whether or not a file is a directory. Again, don't worry too much about this at the moment, although directories can have permissions on them.

In any case, these three columns, when it comes to the ls -la command, prints out the permissions related to the file's owner. So in this case, the Eliot user can read and write to this file. The next three permissions define what a users group can do with this file. So in this case, the users group can only read the file as is. Then the last three characters of this column define what everyone else can do to this file. So users that aren't Eliot and aren't in the users group. These users can only read the file.

So to quickly summarize, there are three permissions you can set when it comes to a file. The first permission is based on the user's owner. The second permission is based on the group ID associated with the file. And the third permission is for everybody else. So how do we go about actually setting these permissions? Well, as you can see, there are three types of permissions in each of the three groups: read, write and execute. These are denoted as R for read, W for write and X for execute.

When it comes to Unix systems, you can change the permissions on a file by using the chmod command, which stands for change mode. As I mentioned, the file mode is the definition of the allowed permissions when it comes to a file in Unix. If we take a look at the help command for change mods, we can kind of get a better understanding of what's going on. Here you can see you've got chmod, then the options, then the modes, and then the file. In this case, there's a number of different ways to perform modes, as you can see on the following regex string.

So the UGOA stands for user, group, other, or all. Those are the first three permissions we talked about: the files user, the files group, and the files other. And then we have the A flag to specify changing the mode for all of these. Then you can use plus minus to add or remove permissions, as well as the equals flag to just set the permissions. Then you have read, write executable. Don't worry too much about what these are at the moment. And you can just go ahead and keep adding permissions to it.

To see what this looks like, if we go ahead and print out the permissions of our file again, you can see only the files user is able to read and write at the moment. But if we go ahead and do chmod g+w myfile.txt, you can see now, if I do ls -lah, you can see now we have the write permission added to the user's file. And now with the write permission added, we can go ahead and remove it by using the chmod g-x myfile.txt. And you can see the write permission no longer exists for my files group.

Using the rwx characters for me is a little easier to understand adding or removing read write permissions when it comes to a file. However, when it comes to both Unix and also programming languages, it's sometimes better to make use of what's known as the bit mask octal. These are three numbers that are used to define the various permissions based on the value of the number, and it uses a bitwise or flag in order to allow you to define what those permissions should look like.

For example, in this case we're actually setting our file to be 0644. The 0 is used to define this as an octal number. Octal defines a number that has three bits inside, meaning it can go all the way from 0 on the lower end with 000 as the underlying bits, or 7 as the maximum number, where it would have the three underlying bits being set to 111. So 4 + 2 + 1 = 7, being full permissions.

As for the following three digits of this number, each one represents a single permission of either the user or the files user, the files group, and the files other. Therefore, you can use each of these three numbers to represent a files mode, and is actually the common way of doing so when it comes to programming languages. For example, if we go ahead and use the chmod command, you can see this in itself also accepts a files mode. And it has a caveat on Windows that only the 0o200 bits owner writable of mode is used. So something just to be aware of, again, Windows has some caveats when it comes to using chmod and also opening the file with a file permission.

In any case, to show what this looks like, if I go ahead and actually remove myfile.txt, and if we go ahead and run our code again, let's go ahead and actually change this to be a main package rather than perms. And if I go ahead and run this code, you can see this time we have a file created, myfile.txt, and it has the same read write read permissions. This is defined by 0644, which in this case 6 defines a write read and write permission, the 4 defines a read permission, and the 4 defines a read permission.

But how to actually understand what the numbers should be? Well, because they're a bitwise flag, there's actually three different numbers you can define. The first is number 4, which equals the read permission. The second is number 2, which equals the write permission. And the third is number 1, which equals the execute permission. So in this case, as you can see, we're setting the read permission, which is the number 4, and we're setting the read permission, which is the number 4. Then when it comes to our user's permission, we're actually setting the read permission, number 4, and the write permission.

Effectively, the number 4, the read permission, and the number 2, the write permission, are being added together, which is essentially what the bitwise OR flag is doing. A bitwise OR flag is taking the bits from the first number and comparing them to the bits of the second number, and for each respective bit, if either of them are set to 1, then the resulting number will have the value set to 1. It's basically doing an OR operation across each value inside of the actual bits.

So for example, if we have the number 2, which is a 010 when it comes to octal, and the number 1, which is a 001, if we OR them together, it will produce the value of 3, which is 011. This is essentially how computers perform addition when it comes to logic gates. So because we have the number 6, we're adding the read permission and the write permission. So if we head back on over to our terminal, you can see that the myfile.txt file has been created with the read-write, read-read permissions, but if we use chmod, and this time we set it to be 666, and we pass in myfile, now when I check the file's permissions, you can see that they're read-write, read-write, read-write.

In fact, it would be easier if I just actually define the file name in the future. And if we want to go ahead and set this back to be 644, we can do so as follows, and pass in myfile.txt. So far, so good. This also works when it comes to Go. If we go ahead and use the chmod command as follows, passing in the myfile.txt. If I go ahead and check the file's permissions, you can see that they are read-write, write, read-read. And if we go ahead and run our code again, and we check the permissions again, you can see they've now been set to read-write, read-write, read-write.

As well as 6 and 4, we could also specify our value to be, say, 7, which means we would also enable the executable mode. Executable mode allows the operating system to execute the file, and is mainly used for files that perform action, if that makes sense. For example, if we take a look at our code, ls -lah, you can see that the executable flag is found on directories, as we can change into those directories, which is the default behavior. But if I go ahead and build my code using go build command, you can also see we have the executable flag added to our perm's file. This is because it's a file we can actually execute, as it's a binary.

Most of the time, you'll want to set the executable flag for things such as scripts, binaries, applications or directories. However, when it comes to things such as text files or source code, then you typically won't enable the executable permission. Additionally, because the executable flag is available in each of the three permissions on the permission set, that means you can change it so that only the file's owner, for example, can be executing that file.

With that, we've covered the basics of file permissions and how they can be used. Next, we need to talk about why they're used and why they're important, and also some caveats when it comes to using the open file command. If we take a look at the documentation again, you can see here that the ocreate flag is passed, it is created with the mode perm before umask. We haven't really discussed what umask is, but in order to show it, if I go ahead and try to create a file with the permissions of 666, and let's go ahead and get rid of the change mod permissions, and we go ahead and do ls, let's get rid of the perm's file as well.

Now, if I go ahead and run this code and do an ls -lah on myfile.txt, you can see our permissions are not 066, they're actually 064. But we've specified 066 in the open file function, which as we know is the correct permissions when we were doing the chmod command. So why does myfile.txt not have the permissions we've set? Well, this is due to the umask, which you can see has 022 defined. The umask defines a bitmask that is applied to our permissions whenever we create a file. You can think of a bitmask as being a sort of bit filter, and rather than adding two bits it will remove those bits from it.

In this case it's removing the bits defined as number 2, which in this case is 010. Therefore it's subtracting 010, or subtracting 2 you could say, if the 2 bit has been set, it's subtracting 2 from the final bitmask. So it turns our 066 into an 044, by masking those bits. This is used as a security measure in order to prevent users from creating files that have too many permissions, and makes a lot of sense.

Of course, we can actually go ahead and change our umask. So let's go ahead and do so, setting it to 000, meaning that we don't mask any of our bit values. Then if I go ahead and remove the myfile.txt, and run the code again using the go run command, this time you can see that our permissions have been set correctly, which if I check umask you can see has no mask bits applied to it. Therefore umask is just a bit of a safety measure, or a failsafe, in order to prevent you from creating files that can be written to by anyone. But in some cases you may want that, so you either have to modify the umask on your system, or you can just go ahead and use the os.changemod command.

Umask will only apply to files that are created. With that, we've covered the basics of file permissions when it comes to both Unix and Go. However, why would we want to set file permissions in the first place? Well, file permissions are an additional security measure when it comes to your system. For example, let's say you have files that contain environment variables or secrets, and you only want the root user of your system to be able to read these.

Let's say you have a web application that you're running on a server, and you set the user who runs that web application to be one that has lower permissions for reading things such as ssh keys or api tokens or anything that you want to keep secure. This means if your web server happens to be breached for any reason, the user can't actually read any of your sensitive credentials. And so file permissions are a really good security measure to prevent sensitive secrets from being exposed.

Therefore, let's say we wanted to create a file that could only be read by the current user in which case we would use 0600. Then if we go ahead and remove this file, meanfile.txt and we'll use the go run command as follows. You can see here now our file permission only has read write access for just the Eliot user and all of the users including the users group cannot access this file.

Speaking of file users, we are also able to change who is the files owner or the user that owns the file by using the change owner command. If we take a look at the help for with the following examples, this command takes a username that we want to change the files owner to and then takes the name of the file that we wish to change. For example, you can see here chown owner and also takes an optional group and the file.

So for example, let's say we want to go ahead and change the owner of myfile to be the root user and also to the root group. In this case, we would go ahead and use chown although I need to use sudo because this is the root user and only the root user can change files to themselves. So sudo chown root:rootgroup myfile.txt.

Now, if we take a look at the file, you can see here the files owner is root and the files group is also root as well. And additionally, because we've set the files mode or file permissions to read, write only for the files owner. If I try and go ahead and read from this file using the cat command, you'll see I get permission denied. That's the permission flags coming in. And if I go ahead and try to write to it, so echo foo > myfile.txt, you'll see I also get permission denied as well.

Additionally, if I go ahead and change the permissions just to show that these are also working. So we'll go ahead and do sudo chmod 640 myfile.txt. Then if we take a look at the files permissions, because it's still the root user, we won't be able to read from it at this stage. We still get permission denied. However, if we go ahead and change the permissions just to show that these are also working. So we'll go ahead and do sudo chmod 644 myfile.txt. And let's go ahead and quickly clear the screen.

If we go ahead and use the chown command again, setting this to be root but users. So the users group can read from this file by passing it in as follows. Check the permissions again. You can see the files group is now users. Now my Eliot user should be able to read from it, which it can, even though there's nothing in there. Let's go ahead and actually write some stuff into there.

So sudo vim myfile.txt. So my sudo user is going to write, we'll do hello world 123. Okay, I should be able to read from it. So read from it as my Eliot user, which I can, but I wouldn't, won't be able to write from it as the Eliot user. So echo foobar baz > myfile.txt, and if we try to pipe this into myfile.txt, again, permission denied.

And if I go ahead and change this, and if I go ahead and change this back to be sudo chown elliot:users myfile.txt, now I should be able to write to it, which I can. Let's go ahead and just write empty to the myfile.txt. Actually, we'll just remove it, set it back to what it was before.

So as you can see, the permission flags do work, especially when we change the owner of this file to be somebody else. And if I had another user to test with, which I don't, if I did have another user, it would also impact them depending on what their permissions are relative to that files owner and that files group.

In any case, that covers the basics of file permissions and how we can use them when it comes to creating files in Go. As I mentioned before, when it comes to Windows, I would recommend using that package we looked at at the start. Or if you really want me to do a deep dive on it, I absolutely will. Just let me know, preferably through Discord. And if enough people want to see it, I'll go ahead and create a video on it. Otherwise, I recommend using Windows Subsystem for Linux.

With that, we've managed to take a look at how we can use file permissions when it comes to creating files, but also how to modify them both on the command line using the change mod command or to change the owner using the change owner command or through the use of the Go standard library, which provides the OS package and similarly named functions from it, such as the OS.

The last thing to mention is what the default permissions typically are when it comes to both files and directories in Linux. For files, it's going to be 0644, which means read, write, read, read. And for directories, it's going to be the same, but just adding the executable flag. So 0755. If you're ever unsure about which permissions to use, I would recommend defaulting to these and changing it if you happen to have a good reason to do so.

In any case, in the next lesson, we're going to take a look a little bit more at the file system and how we can actually traverse it using some of the primitives when it comes to Go.