Wednesday Challenge: The Permissions “Lie” (403 Forbidden)

[TudorRaduta]

A classic trap hidden beyond ls -l

Happy Wednesday. Time for another From Problem & To Polish scenario.

We usually trust ls -l to tell us who can access a file. But sometimes it tells you everything is fine, while the system quietly blocks access anyway.

Today’s challenge digs into a classic pitfall where permissions look correct, but SELinux has the final say.

The Scenario

You’re setting up a simple web page. You create the file in your home directory:

[user@server ~]$ vim index.html

Then you move it into the web server directory:

[root@server ~]# mv /home/user/index.html /var/www/html/

You check permissions with ls -l. Everything looks right. The file is readable.

But when you access the page, Apache or Nginx returns a 403 Forbidden. The audit log shows an AVC denial.

Your Challenge

You’ve run into the classic mv versus cp trap. Let’s break it down.

1. The Diagnosis: ls -l isn’t showing the full picture. What flag do you add to reveal the SELinux context?
2. The Cause: You see the file labeled as user_home_t. Why did it keep that label after being moved into /var/www/html?
3. The Fix: What single command immediately restores the correct SELinux labels on everything under /var/www/html?

• Bonus: If you had used cp instead of mv, this problem wouldn’t have shown up. Why not?

Who can spot the real permission issue here? Share your answers below.

[sr5]

restorecon -R 

 /var/www/html/index.html 

[sr5]

cp instead of mv, this problem wouldn’t have shown up. Why not? Because it retains the selinux permissions

[Ad_astra · Accepted solution]

Hi 

My answers are:

1) The -Z option for the ls command will show the SE Linux contexts. For example; ls -lZ.

2) Moving a file retains the SE Linux file context of the directory it was created in. This means the SE Linux context will be incorrect for the directory that the file is being moved to. 

3) Running the following command will change the SE Linux context on the moved file and restore the defaults to any other files in the directory:

sudo restorecon -Rv /var/www/html/

Bonus) When you copy a file, the file system creates a new file in place. The new file is created with the default SE Linux context/labelling rules for the directory it is created in. Copying a file from one directory to another keeps the original file context and labelling from the original directory. 

[Architect_005]

Hi
Find the details

The Diagnosis: ls -l isn’t showing the full picture. What flag do you add to reveal the SELinux context?
# ls -lZ
- This reveals the SELinux security context (like httpd_sys_content_t, user_home_t, etc.).

The Cause: You see the file labeled as user_home_t. Why did it keep that label after being moved into /var/www/html?

- When you move () a file, SELinux does not relabel it. It simply keeps the existing label because the inode is preserved — only the directory entry changes.
- So if the file was originally in with the label , moving it into won’t trigger a relabel. It still carries , which Apache () cannot read.

The Fix: What single command immediately restores the correct SELinux labels on everything under /var/www/html?
# restorecon -Rv /var/www/html

Bonus: If you had used cp instead of mv, this problem wouldn’t have shown up. Why not?
- When you copy () a file, a new inode is created in the destination.
- SELinux applies the default context for the destination directory to the new file.
- That’s why into would have automatically given it the correct label.