Check out a free preview of the full Full Stack for Front-End Engineers, v2 course:
The "Permissions" Lesson is part of the full, Full Stack for Front-End Engineers, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jem demonstrates how to look into the server's permissions log.

Get Unlimited Access Now

Transcript from the "Permissions" Lesson

[00:00:02]
>> Jem Young: All right, another thing we we touched on is something called permissions. So permissions kind of are based on this idea that eventually someone probably will get into your server. That's not actually true, but it's kind of thinking along those lines. Permissions mean you're locking down what you can do with a file.

[00:00:22] And those things, actually I'll ask you, what are the things you can do with a file? And there's only three things, and they're pretty fundamental. Yes?
>> Speaker 2: Read, write, execute.
>> Jem Young: Exactly, you can read a file, you can write to a file, and you can execute that file if it's some sort of program, and permissions are all about controlling that.

[00:00:42] For instance, we use sudo for everything because we don't have permission to modify, say, the firewall or something like that. So we're using the super user power to do that. Which means if someone came into my server and they don't know my sudo password they can still cause a lot of trouble.

[00:00:56] But they're gonna be very limited in their blast radius because they don't have that route permission, which pretty much ignores all of the permissions. So we have this concept of file permissions. Yesterday we modified our authorized key file to be readable and writable by only us and the super user because we don't want people coming in and modifying that key file if they don't have access to my account or the root account.

[00:01:22] And I mentioned that the decode, the numbers that we use are kind of arcane. There is a conversion that converts what's readable and writable to my user versus the root user, but I've looked it up once and it's really complicated. So it's better just to memorize the ones that you only need.

[00:01:43] I'll say this, it's really tempting. You've probably seen code examples to use the chmod command. So that's change modification, which means permissions for a file. And it's really easy just to be, well, I need this file to be read and I don't have permission to do it right now so I'm trying to execute it.

[00:02:01] And that can only be executed by the super user so I'm just going to make it chmod 777. That's one you see all the time, and that's what's known as the laziest permission because it means you don't have to think about permissions. It's just open to everybody. You shouldn't do 777 unless you really know what you're doing or, I won't say you're in a hurry, cuz [LAUGH] that's so bad.

[00:02:22] But if you're in a hurry and you're trying to execute a script and it has no security ramifications you can use 777, but you generally don't. We're not gonna do too much with permissions, but if you wanna take a look at them. Let's say we're in our home directory, there's nothing major.

[00:02:39] So we can say ls -la and it's gonna tell me all the permissions for read, write. And so it's read, write, execute for myself, read, write, execute for my group, which is sudo, and read, write, execute for everyone. And that's what the permissions, I really wish they would map chmod to the actual commands here but they don't.

[00:03:04] So you just have to memorize some of them. But if you see 777 it's gonna be read, write, execute across the board for everything. Just don't use that one. And actually, I'll just look up man chmod.
>> Jem Young: Change file mode bits, yeah.
>> Jem Young: Maybe for a bonus trivia over lunch we can look up what exactly maps like a four to the permission level.

[00:03:31] And there is a mapping, it just is not intuitive.
>> Jem Young: But in general, you always wanna have the least trust for your file. So if a group or user doesn't need to specifically access a file, just lock it down. You want to have the least permissions as possible just in case someone gets into your server.

[00:03:53] Or think of a case in terms of DevOps. If you're running a server for lots of users, you don't want them to be able to enable permissions for everybody because one of those users is probably gonna have a bad password or something like that or a bad key that got stolen.

[00:04:09] And if someone breaks in with that, you want them to be able to do the least amount of damage.