(The updated version of this series can be found here (gone).)
Linux is an implementation of the Unix computer technology; a type of Unix, if you will.
In Unix Land, everything is a file. Every bit of hardware that the kernel recognizes is treated as a file, too. So while Linux can recognize multiple hard drives, they aren’t listed as they would be in Windows using single letters of the alphabet. When you go hunting through your system, the various kinds of drives are listed under a “device” folder. You won’t see “C:” and “D:” and so forth. You are more like to see “/dev/sda” and “/dev/sdb”. Please notice that most folks use the terms “folder” and “directory” interchangeably.
Meanwhile, the root of the file system is not designated by a letter, but the forward slash symbol by itself: / — standing at the front of any string of letters and numbers representing parts of the rest of the file system. Thus, any location within the file system would start with the root (/) followed by the various sub-directories by which things are organized. There won’t be a “Linux” folder like you have a “Windows” folder, or “Program Files” because the Unix concept is a little different. You’ll see the root of the file system branching off in things like “/usr” and “/home” and so forth. Rather than bog down with all the mind-numbing details (this is a decent tutorial), we’ll focus for now on that last item — /home.
On your XFCE desktop by default is an icon labeled “Home”. That’s your “home” in the file system. You own that stuff and can do pretty much what you like with it, because the rest of the system is protected from what goes on there. If you double-click that desktop icon, you’ll get a pretty simple file manager window, and this file manager is called Thunar (no, I had nothing to do with all these funny names). As with any other graphical system, you can either drag the corners or sides to get a different size (the pointer changes shape to indicate it). On the left is a column listing the most common places inside your home directory that most people visit. Technically, the location of your home within the file system is “/home/” followed by your login name. Mine says “/home/ed/” — notice we put the forward slash between each directory label (instead of the Microsoft “back slash”). It’s not absolutely necessary to put the trailing slash on there, but it’s technically precise to designate that it’s not a file, but a folder with more stuff inside it. Also, in the standard Linux jargon, you’ll often see it written as “$HOME” — this is how we indicate a system variable. It translates to “home” for whomever has a home folder on any system. You may also see the abbreviation “~/” (tilde slash).
There are also a lot folders and files you don’t always see. They aren’t secret, just kept out of the way of normal operations. So to make them “hidden” in that sense, we place a period (or “dot”) at the beginning of the name so we don’t have to look at it all the time. All your personal configurations are kept in folders and files with dots in front of them — “dot files”. If you want to see them, in the menu of Thunar click on View > Show Hidden Files so that you place a checkmark in front of that menu item. Then you’ll see displayed in the window a considerably larger number of icons. As with any other graphical file manager, Thunar can be adjusted to change how things are displayed. I prefer a detailed list, but that may not be your cup of tea. Explore the menu and settings and decide how it works for you.
One of the items I always set in choosing what columns to display in that list view is adding the “permissions” column (View > Configure Columns and checkmark “Permissions”). In Unix Land we assign permissions to the file system and they are strictly enforced by the kernel. That’s one of the reasons Linux tends to be so stable and secure: The system tightly restricts who can do what with the various files. Because the administrator account (“root”) can do anything at all, we avoid logging in with those credentials until necessary, lest by accident we delete something important. Unlike other operating systems, root can delete the whole thing while the system is running. There are good reasons for this, to include you as owner having full authority over your own system, but we won’t cover that in detail right now. Instead, just keep in mind that it requires root login credentials to do anything to the system, so we always run the system as a common user with limited power to mess things up.
If you really want to understand it in depth, try this tutorial. For now, we focus on the most basic concept. Unix is designed for multiple users, so even if you are on your own home computer and you are the only user, the file system still assumes multiple users. Every file on the system has three basic types of permissions based on the various roles on the system. Every file is owned by somebody, and in regards to file controls, we call them the “user” (u). Every user belongs to several “groups” (g) that may share various levels of permissions on some files. Anyone else who legitimately logs onto the system, but is not a part of your groups, is “others” (o). Thus, the permission controls will include designations with combinations of “ugo” — user/group/others. If you want to designate them all together, it’s “a”. For each of these roles, there are three levels of permission: read (r), write (w) and execute (x). There could also be an absence of any permission. Some files can be turned into executable commands, such as scripts (in Windows Land, that would be “batch files”). The difference is not how the file is labeled, but what permissions it carries. You could simply write a script of commands in a series, save that list of commands to a file, and make it executable by setting the execute permissions to run it as a script. Meanwhile, you could let people run it, but not read it or change the contents. Permissions are specific, not inclusive.
In your file manager window, right click on any file in your home folder (or subfolders). The context menu will include “Properties…” Select that and a dialog opens with several tabs, one of them labeled “Permissions.” You’ll see the various drop down items to change permissions. You’ll also notice the name of the user who owns it, the applicable group name for this particular file, and something about “others.” On each, you can set different levels of permission. You can even lock yourself out of your own files, though you retain the authority to change that because you own it. Group membership is seldom of much interest on a single-user system, but it becomes important when you need permission to do certain things from your user account. Belonging to certain groups allows you to use certain pieces of equipment, because you belong to the same group to which that hardware is assigned. It’s a complex way of controlling what can and cannot happen on the system to avoid losing control of how it works.
For this reason, it is exceptionally difficult for someone to write malware for Linux. There are no secret permissions and hidden controls. When you log into your user account, you can surf the Net and anyone trying to stick files on your system through your browser can only have your user account’s authority. They can’t slip in a script or executable file with full access to the system. The worst they can do is delete some of your personal files — that’s what backups are for — but can’t attack the actual system.
As for security holes in the underlying system, the Debian developers are famous for patching stuff as soon as they discover one. There is a strong system in place just hunting for such problems, and it’s quite rare that the bad guys find them first. Most such holes require someone working directly against you while you are online, and most of us simply don’t have anything they want that bad. It’s too much work for too little return.
In our next lesson, we will learn how to check for updates on Debian.
I really enjoyed reading this article about Linux. I like the way you explained some of the differences between it and Windows. I personally love the way that security in Linux is not merely an afterthought because of people whining about it, but something built into the kernel itself. After reading this I look forward to more articles from you.
Thanks, Anthony. Hopefully I can justify your confidence in me.
After checking out the three Debian articles I know you will
Based on what I read you will
Reblogged this on anthonyvenable110 and commented:
Very well thought out explanation of Linux