Now we do want to make sure that this is practical that we're looking at,
and we're going to take a look at deploying our Apache Web Server with
the correct permissions and umask in place.
Now, working throughout our command line, I have already configured my umask.
When I look at my umask, it's set to 27, so as we said before,
it's removing write permissions from the group and all permissions from others.
I always think this is a good starting permission for your umask, and
we've seen its use within our shared directory.
But if we go through and just extend to this to see a very practical way
that we can get things up and running really quickly with an effective
umask and correct permissions on the directory.
If I go through a look at sudo and yum install, and we want the
httpd, if you're doing this on a Debian‑based system,
it would be apt install and Apache too.
We want to put it on the Apache Web Server. We can go through
and accept the work that it's going to do,
allow it to struggle ahead, and get our web server installed.
Now,
before we start it, it will be running on a Debian‑based
system, but it won't be running on our Red Hat‑based
system, such as we're using here.
If we take a look at the permissions that are in place, so
ls ‑ld to look at the directory, /var/www and then /html.
Now, when we take a look at it,
even though this is based on Enterprise Linux, the permissions are by
no means Enterprise ready. We can see that the group root owns this
directory. It's owned by the user root.
The web server itself is gaining access through world‑readable permissions.
They are not listed as a user or group.
So Enterprise Linux thinks that it's perfectly okay to allow the world access
through to your directory with only the service account, and maybe the root user
needs access to this directory. It's utterly abysmal. But we can change this
really quickly and change it for the better.
Others do not need access to the directory. Even though this is going to be
a web server that needs to be accessible by everyone, they are accessing
the web server through the web server account.
We access the web server,
it is the web server that is accessing the directories and the files. So
we can go through and ensure that it's set up properly.
So the first thing that we're going to do,
if I look at tail /etc/group,
we can go through and look at the last group that was
created, and we can see the group is Apache.
So that is the group that needs access.
So if we do a sudo and chgroup apache for then our
directory, that set up the correct ownership.
We can then go through and change the permissions, so chmod ‑v, and we
can go through and set up the permissions that we want.
So we want 2750.
We only need read and execute as the group.
The group being the Apache group shouldn't be able to write to this.
If somebody does gain malicious control of your Apache
server, then the Apache server doesn't have the ability
to write to the web directory.
We don't need to set anything other than the group ID bit here
because we don't need to control deletions because we don't have
the write permissions set for the group.
We can go through to set this then on the directory.
We can see then that it's changing through.
We've got the group ID bit set on the directory.
Now we've already seen that we've got the correct umask.
The most effective or the strongest umask is going to apply when we use sudo.
So even though I've only set my umask for my user account,
it is going to be a stronger umask, and it will be the effective one when I use
sudo. So if I go through and use sudo and vim, we'll create a simple web page
and put that in then our /var/www and html and index.html, we'll create
ourselves a web page. So with that in place, we can go through and edit it,
"this is my page." Go through and save this.
If I go through then to do an ls ‑l on that file, I
don't have permissions to it.
As an ordinary user, I don't have permissions into the directory.
That's kind of what we want.
I can only access the web page by accessing it through the web server.
The web server might have extra restrictions it wants to
put on me that I have to log in to see that I have access
through to certain content.
If I was able to access it as an ordinary user, I can bypass that.
So we certainly don't want permissions granted to others, and we can see
then that that's working exactly the way that we want.
Okay, well, let's do a sudo and !!. Repeats the last command, but with sudo in
front of it. And we can see then we've got permissions read,
write, and read, so we can see the effect of our umask. We've made
sure that no permissions have been granted through to others, and
it's correctly owned by the Apache group.
The Apache group can read this file. So we haven't had to do
anything, and obviously any more content that is created is going
to be automatically configured correctly.
So we've really set a policy in place to ensure that everything is going to work
out of the box. As we then go through and do our sudo and systemctl start httpd,
and then just go through quickly curl to localhost, we can see then that the web
server is able to access the page.
And as a standard user, so long as I'm accessing it through the
web server by browsing to my web server address,
I'm able to read the content. Again, any security that we put in
place from a web server perspective would be applied, and that's how we control access to our data.