Linux Files

Files are central to Unix in ways that are not true for some other operating systems. Commands are executable files, usually stored in standard locations in the directory tree. System privileges and permissions are controlled in large part via access to files. Device I/O and file I/O are distinguished only at the lowest level. Even most interprocess communication occurs via file-like entities. Accordingly, the Unix view of files and its standard directory structure is among the first things a new administrator needs to know about.

Access to files is organized around file ownership and protection. Security on a Unix system depends to a large extent on the interplay between the ownership and protection settings on its files and the system’s user account and group† structure (as well as factors like physical access to the machine). The following sections discuss the basic principles of Unix file ownership and protection.

File ownership

Unix is a multi-user file system and thus should provide a way to control and easily manageable access permission. This is where Unix becomes a little more complex than other operating systems. It not only relies on user permission, rather has another constraint called groups to provide certain control over files.

The motivation behind this group ownership of files is to allow file protections and permissions to be organized according to your needs while providing the flexibility that one may desire.

It helps to arrange a user into one or more groups and restrict access based on that. Files can be made accessible to any number of system users. Files can be given access to anyone in the system as others. Typically, that means that the user does not need to be the owner of the file or be a part of the group to obtain access to the file. Let's get started with some command and examples:

How to list the permission of a file

/tmp ❯ ls -al                               
-rw-r--r--  1 singh  cs 0 Mar  8 14:04 test

As you can see that the file is owned by the user SINGH and the group is CS.

Columns three and four display the user and group owners for the listed files. For example, we can see that the file test is owned by user SINGH and group cs.

Understanding ownership

When a file is created, the user responsible for creation owns it. In the Linux, group the owner of the directory is marked as the group owner of the new file also. Let’s see how can we change ownership:

/tmp ❯ sudo chown root test              
/tmp ❯ ls -al test                         
-rw-r--r--  1 root  wheel  0 Mar  8 14:04 test

Let’s see this behavior when applied the same on the directory and see that in this case, Linux does not differentiate between a directory or a file.

/tmp ❯ sudo chown root:wheel test2
/tmp ❯ ls -l                   
drwxr-xr-x  3 root      wheel   96 Mar  8 14:13 test2

However, to apply the same for all the files in the directory, let's try the below command, we would need to use -R to recursively apply the same to all the files in the same directory.

/tmp ❯ sudo chown -R   singh test2
/tmp ❯ ls -l test2                             
total 0
-rw-r--r--  1 singh  wheel  0 Mar  8 14:04 test

Protection

Linux and Unix care about file protection also. Once set up correctly, a file can be protected from unwanted intruders and other users also. In Linux a file can be protected using file modes, hence the command to modify the protection is called `chmod`.

Unix supports three types of file access: read, write, and execute, designated by the letters r, w, and x, respectively

Protection for directories

The corresponding meanings for directories may seem strange at first, but they do make sense. If you have an execute access to a directory, you can cd to it (or include it in a path that you want to cd to). You can also access files in the directory by name. However, to list all the files in the directory (i.e., to run the ls command without any arguments), you also need a read access to the directory. This is consistent because a directory is just a file whose contents are the names of the files it contains, along with information pointing to their disk locations. Thus, to cd to a directory, you need only execute access since you don’t need to be able to read the directory file itself. In contrast, if you want to run any command lists or use files in the directory via an explicit or implicit wildcard — e.g., ls without arguments or cat

Some items in this list are worth a second look. For example, when you don’t have access to any of the component files, you still need only read access to a directory in order to do a simple ls; if you include -l (or any other option that lists file sizes), you also need execute access to the directory. This is because the file sizes must be determined from the disk information, an action which implicitly changes the directory in question. In general, any operation that involves more than simply reading the list of filenames from the directory file is going to require execute access if you don’t have access to the relevant files themselves. Note especially that write access on a file is not required to delete it; write access to the directory where the file resides is sufficient (although in this case, you’ll be asked whether to override the protection on the file): $ rm copper rm: override protection 440 for copper? y If you answer yes, the file will be deleted (the default response is no). Why does this work? Because deleting a file actually means removing its entry from the directory file (among other things), which is a form of altering the directory file, for which you need only write access to the directory. The moral is that write access to directories is very powerful and should be granted with care.