#examplelink

One of the the basic foundations of working with Linux is delegating file access permissions: who can access the file and who can manipulate it. Default file permissions for system files are usually already set by the OS. However new files created by users and third party programs need to be taken care of manually. Missteps in setting up file permissions can lead to problems with the system, newly installed programs, and potentially increase security risks. More importantly, this can lead to authentication and authorization errors. For example, when you try to setup key-based access to your server, generate the keys, put them into a folder and accept access permissions of that folder, try to connect but.... the server is still asking for a password. If you look into the system journal you'll see the following:

Permissions 0755 for '/Users/username/.ssh/id_rsa' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored

Obviously! We put the key into a public folder, that's accessible to anyone... even the server figured it out. Doing stuff like that not only leaves your server open, but any other server that might be using that same key for access. Sometimes you might hit an error when trying to create a directory:

mkdir: cannot create directory `/home/myfiles': Permission denied

Again, the problem is file permissions. Basically, every file created- either automatically or manually- in Linux will have some kind of permissions already assigned to it. We'll need to be able to look through, understand, and modify them. Checking Permissions The common command for getting a list of folder contents is "ls -l":

ls –l total 4 lrwxrwxrwx 1 root root   11 May 27 19:47 examplelink -> examplelink drwxr-xr-x 2 root root 4096 May 27 19:46 mydirectory -rw-r--r-- 1 root root    0 May 27 19:45 script.sh -rw-r----- 1 root root    0 May 27 19:45 simplefile.txt

Here we got four basic kinds of files: 1. A shortcut "examplelink" 2. directory "mydirectory" 3. Script file "script.sh" 4. Simple text "simplefile.txt" You can see the corresponding file attributes in the column to the left; from left to right they describe the nature of the file ('-' basic file, 'd' directory, 'I' symbolic link/shortcut) and the access permissions for this file. The next three symbols refer to the permissions of the primary user, the primary group of that user, and, finally, anyone else who might have potential access. For the file 'simplefile.txt,' the user (root) can read (r) and write to (w) the file, which includes moving and/or deleting the file. A dash means that this file can't be executed, meaning that running it as an application won't work. Other users in the group 'root' only have read-only access (r--), including seeing the file's attributes, while everyone else don't have read access to begin with (---). For the 'mydirectory' file, the parameters are very similar except for the execute parameter (x) for the last group. This designates the file as being executable as a program or application. Take note that the 'script.sh' file is executable, however no user or group has permissions to do so. At this point, it should be obvious that in order to maximize system integrity we really need to assign file permissions on a file by file basis as much as we can.

Modifying Permissions

IMPORTANT: Modifying some permissions, especially if you have root privileges, can severely disrupt the entire OS. Pay close attention to what you're doing, and test everything before executing. Don't forget to make backups before modifying anything, especially for larger files and directories, and store it in a secure location. When modifying permissions, pay attention to the way you use the '/' symbol in file paths. Using the command "chmond u-x /home/username", if you put an extra space in front of the first '/' by accident you will actually revoke execution permissions for every file on the server! The 'chmod' command, by the way, is how you change file access permissions. For example if you attempt to run the 'script.sh' file from before, it won't work:

./script.sh bash: ./script.sh: Permission denied

So, we'll use the following command:

chmod u+x script.sh

Let's unpack that real quick: using the 'chmod' command we're allowing (+) the user (u) access to execute (x) the file 'script.sh.' When we check the file attributes we should see:

ls -l | grep script -rwxr--r-- 1 root root    0 May 27 19:45 script.sh

You should be able to see the 'x' listed in the attributes, which let's us know this user can now run the file. If the file has information you're trying to hide from the rest of the group, you will need to revoke read rights from everyone else in the group:

chmod go-r script.sh

Here, the other users (o) of the group (g) are getting their read (r) permissions revoked (-). You can change up this command to substitute the 'o' for 'a' (all) to remove permissions from everyone in the group. Using the 'a' tag will include permissions even for the root users until they modify those permissions again. When using this command to change permissions for a directory, you will only be changing permissions for the directory and not for any files or subdirectories in it. In order to include files and subdirectories you need to add the tag '-R' to the command:

chmod -R g+x ./mydirectory

It's actually easier to assign permissions using a number system, so let's go over that real quick. Remember when we were going over the private keys we used to access the server without a password. If you created them like regular files, they will have the default rights 655 which corresponds to the primary user having read-write access, and everyone else having read access. So for the key folder, it's enough to just have read access to these files:

chmod 400 /home/myuser/.ssh/id_rsa

Or if you need to give access to the entire folder:

chmod -R 400 /home/myuser/.ssh

Here's the shortlist of common numerical commands used to modify permissions:

400- the primary user has read-only access, and no one else has access. 600- the primary user has read-write access, and everyone else has read only access. file can't be executed. 700- same permissions as 600, except that the file can be executed.

Normally, the group only needs read access, but in some cases you might encounter these commands as well:

777- this will allow complete access for any and every user, to read and write. Generally, this permission level shouldn't be used. 660- everyone has read-write permissions, but the file cannot be executed. 644- the primary user can read and write, but not run. Everyone else has read only access.

Expanding Standard Permissions

In order to assign permissions to users across multiple Linux distros, and a variety of file systems, you will need to install 'acl' and 'attr' packages. This is especially true for users using Samba and using file systems based on ext4.

So, to summarize, the main issue with file permissions is to properly limit file access to users and groups on a case by case basis. Depending on your needs, you may have to give every user unique and, sometimes, complex sets of parameters.

Hope this article helped you out. We're not quite done with Linux file permissions; our next article will go deeper into this topic, so stay tuned. Always remember to follow ServerSuit on Facebook and Twitter to keep up with new articles. Until next time!