In this tutorial, we will be installing Moodle on an Ubuntu 18.04 server.
Moodle was originally released in 2002 and has been translated to over 100 languages ever since, making it accessible to as many students and teachers as possible. The installation process shouldn’t take much time, so let’s get started. (more…)
In this tutorial, we will show you how to install MediaWiki on Ubuntu 18.04 server.
In this article, we will show you how to install Jenkins on Ubuntu 18.04.
Jenkins can be installed on Windows, macOS and on most of the Unix-like operating systems, such as Ubuntu. Let’s get started with installing this useful piece of software.
In this article, we will show you how to install the Shopware Community Edition (CE) on CentOS 7 server.
In this tutorial, we will guide you through the steps of installing Dotclear on a CentOS 7 server, with Apache web server, PHP and MySQL.
The role of permissions and files is much clearer in Linux when compared to Windows. Most people find it easier to understand compared to the complex system of groups and users that we find in Windows’ concept of permissions. For example, each file in a Linux-based operating system has three sets of permissions – the first being the permissions of the owner, the second being for a specific group of users, and the last group’s permissions are responsible for the rest of the system.
The levels of access to reading, writing, and executing are then described with a scale, ranging from 1 to 7. A value of ‘1’ allows for execution of the file, ‘2’ allows writing access, and ‘4’ allows the file to be read. To combine several permissions, you just add the numbers together. For example, if you want read and write access for a file, but no access to executing this file, the value to set for permissions would be 2 + 4, which is 6.
In this tutorial, we’ll see how to create a file in such a way that only the owner has full permissions over it. We’ll also see what happens when another user tries to read or modify that file. Finally, we’ll look at the role of “sudo” users who take on the root role for themselves, and how we can implement ironclad file security by hiding contents even from root if necessary.
Let’s say we have a file whose contents we want to have hidden from everyone else. In essence, others would be able to see that the file exists, and that’s about it. We don’t want them to see what’s inside it, or be able to modify it in any way. We do this using the following command:
chmod 700 test.txt
Where test.txt is the name of the file that I want to protect. Once we run this command, the file turns “green” when you list it in a command like “ls”, and it displays the new file permissions with the “ls -l” command, like this:
Here, you can see the file permissions are restricted only to the first group – the owner – who has “rwx”, or read, write, and execute permissions. And the third column of “ls -l” is the owner name, which in this case is “root”.
For convenience sake, we’ve created this file in the home directory of another user called “testuser”. Here’s what happens when we log in as the new user and try and read the contents of test.txt:
As you can see, testuser is denied the ability to access the file in any way. Any other user who tries to open this file will get the same error message. In this way, you can ensure that your important files are kept hidden from other users.
Perhaps there’s an important document or set of rules that you want others to be able to read, but not modify. We can achieve this using the following command:
chmod 744 test.txt
Here, “744” instead of “700” gives everyone else the permission to read the file, but nothing else. Here you can see that “testuser” is able to access the contents of the file after it has been assigned its “744” permissions:
However, if they then try and modify the file using a file editor, like “vi”, they get the warning you expect as shown here:
Use this variant of the chmod command when you need others to see the file, but not modify it in any way.
Unfortunately, file permissions don’t apply to root or sudo users. For this example, I’ve added “testuser” to the sudoers file so they can use execute root commands using sudo. And when they do this, they can access the protected file as shown here:
There’s no way around this using file permissions. Root, and users belonging to the “wheel” group can simply use “sudo” to get around these restrictions. Of course, it’s good practice to be wise with the capabilities you give your users – handing out sudo permissions to everyone is not a good idea. Since this is common practice, well-configured Linux systems shouldn’t have this problem.
Ultimately, the only way to hide your files from everyone – including root users – is to use passphrase-based encryption. No other method can hide your information with 100% security from everyone, including the root and sudo users!
Of course, you don’t have to do any of this if you use one of our Outsourced Server Support Services, in which case you can simply ask our expert Linux admins to set up your file permissions for you. Just sit back, relax, and let our admins take care of the issue for you. They are available 24×7 to help you with your requests.
PS. If you liked this post on denying file permissions to everyone except yourself, please share it with your friends on the social networks by using the share shortcut buttons, or simply leave a comment in the comments section below. Thanks.
Linux is an operating system of text files. Unlike Windows, the Linux philosophy and core concept is that “everything is a file”. Sure, there are databases and binary structures, but nothing like Windows’ “Registry” exists. Even devices, partitions, and sockets are represented either by real or virtual files.
Given all of this, some text files can get pretty big. And often we’re not talking about dozens of MB, but possibly hundreds, or even a few gigabytes in size in rare occasions. And all of it can be text! In fact, something as innocuous as a log file can continue to grow if left unchecked. Let’s say you have a file recording every visit to your website, along with the date, IP, user-agent, etc. For even a medium-sized website, that file can grow pretty large if not dealt with.
By default, all Linux installations have plain black and white color prompts. Specific commands are coded to have color combinations under certain circumstances. For example, directories in the “ls” command are coded blue by default, and scripts are colored green.
Similarly, the frequently used “grep” command is also color-coded to highlight matches. However, the Linux prompt itself is rather innocuous. In this article, we’ll show you how to change it to anything you want – a single color, or even a combination of them. Let’s get started.
Back when Linux was in earlier development, it used to utilize a “flat” directory structure. This meant that unlike the hierarchical “tree-link” folders we have today, everything was located inside of a single folder. No subdirectories existed. It also meant that each file had to have a unique filename, without exceptions!
All of that changed when Linux baked “hard links” into its kernel. The special character sequence “..” was defined to mean the parent directory, and it’s now the backbone of the modern Linux filesystem as we know it today. With that, we can see the importance of hard links – and in this tutorial, we’ll explain the difference between symbolic links and hard links, and the use-case scenarios, as well as when to use each type of link.
Sometimes, working with YUM – the default CentOS package manager – can feel unintuitive and cumbersome. Sure, it’s better than using the even more barebones RPM package manager, but it still leaves a lot to be desired. Take YUM’s “history” command, for instance. The idea of that command is to give you a general idea of what package operations you’ve carried out recently. So if you’ve been installing stuff, upgrading older packages, or updating CentOS itself, YUM will keep a record of it all.