228: Filesystem: What Can They Do? Part 2.

Security is a big part of filesystems. This episode will explain how traditional file system security works for Unix, or Linux, or Mac computers. They all follow a similar design. These operating systems could have another security system depending on the version. I’ll describe that system in another episode. You can read the full transcript of this episode below. Transcript But you can’t have a secure filesystem if you don’t understand how it works. This is one thing you’re bound to come up against when programming. Just like when you come home and need to unlock your house door. If you forget your key, you get locked out. The types of security problems you’ll be likely to face as a programmer are not usually the type where you forget the key. You’ll be more likely to face issues where you have to manipulate the locks, or pass your identity to other parts of your program, or even take on a different identity for a while. Let’s say you do forget your house keys for a moment. After calling a relative with spare set of keys or the locksmith, you might be interested in things you can do to prevent this from happening again. One solution is to just stop locking your door. Or hang the key from a chain next to the door on the outside so that anybody can use it. Would you consider doing this? Well, maybe if you live in a small rural town. But even the small towns are likely to lock their doors. I remember a restaurant from when I was a kid that had no locks on the doors. The place didn’t need locks because it never closed. Chances are, you want to keep your locks. So why does a common recommendation online to programming security questions advise you to set the security of your files or directory to 777? That’s for a Unix computer system anyway. For Windows, a slightly less common advice is to add everyone to the access control list. Both of these approaches are the equivalent of letting anyone use your keys anytime they want. The filesystem can’t help you if you give it specific instructions to let anyone in. It should always be your goal of identifying the absolute minimum privileges needed by only those who should have access at all. This episode will explain how traditional file system security works for Unix, or Linux, or Mac computers. They all follow a similar design. These operating systems could have another security system depending on the version. I’ll describe that system in another episode. Understanding this design will give you the ability to configure your files so that you have just the right amount of permissions. But first, why is this important? I mean, sure, we want to keep bad people and applications away from our information. But assuming you have a good reason to have access, why not just grant full access? Let’s say you arrive for work and walk in the front door. You might have a badge or maybe everybody already knows who you are. You have access. Does that mean you should have access to the company bank account too? What about the company plans for the next 5 years? Security is not a switch that gets turned on or off. There are levels. There are restricted areas. And for large organizations, there can be a lot of changes as people come and go and move from one department to another. Let’s start with you though. If you create a file, then it should probably belong to you. You should be able to open it again and make changes. You should be able to move it to a new folder or to delete it. And if the file is something that can be run like a script or an application, then you should be allowed to run it. Traditional Unix based filesystems divide security into read, write, and execute permissions. You can either read the file or not. And you can either write changes to the file or not. And you can either execute the file or not. Each of these switches can be turned on or off individually. Although it’s normal that if you can write