RHEL6 – Using htpasswd to Create a Secure Apache Directory

Bank-vaultThe process of setting up a simple password protected web directory on an Apache server is rather easy. The simplest way to accomplish this task is to use flat-file user authentication. Disclaimer, I am not claiming that the directions below are the most complete, or the most secure. However they work and are probably the most simple.

The first thing that you need to do is to create a "secret" directory. In this instance my web root is /var/www2/html, so I will create my secure directory under that tree.

#mkdir /var/www2/html/secret

Now lets create an index.html inside our secret directory for the purpose of testing.

#echo "Secret Directory Working" > /var/www2/html/secret/index.html

This way we have something to look at when we actually are able to get this working correctly.

Now using the htpasswd command we need to create an htpasswd file and add a user that will have access to our top secret directory. Note that you should not create this file inside your web-root.

#htpasswd -c /etc/httpd/.htpasswd fatmin

In the example above the "-c" option creates our htpasswd file, fatmin is the user that we want to grant access to. You will be prompted for a password.

Now add the following stanza to your httpd.conf. Note that AuthName is the text that will display when the user is prompted for a password. AuthUserFile is the location of the password file. Basic is pretty much the only auth method that anyone uses.

<Directory /var/www2/html/secret>
AuthName "Secret Directory"
AuthType basic
AuthUserFile /etc/httpd/.htpasswd
Require valid-user

Now restart apache, and when you navigate to http://www.mysite.com/secret you should be prompted for a userid and password.



SELinux – Invalid Regex in /etc/selinux/targeted/contexts/files/file_context

EnikSo I have been doing my best to better understand SELinux as of late, and last night when I was practicing I ran into an issue that had me banging my head against by desk.

Specifically I was playing around with the semanage command and working on defining a particular context to a directory that I had just created. However I was not exactly quite sure of the exact regex to use (or even if I needed to use a regex)

The specific command that I ran was…

#semanage fcontext -a -t httpd_sys_content_t /var/www2

Now my concern was that this was not the correct command for me to run since www2 was a directory and I wanted to make sure that appropriate SELinux contexts were applied recursively as new files/directories were created. So I ran the following command that I found in my RHEL book.

#semanage fcontext -a -t httpd_sys_content_t ‘/var/www2/html(*,/)’

which spits out this….

/etc/selinux/targeted/contexts/files/file_contexts.local:  line 13 has invalid regex /var/www2/html(*,/):  Invalid preceding regular expression

Oops, wait I entered the command wrong. Its a period and the end not a comma, so I run the command again with a period this time and get the following error.

# semanage fcontext -a -t httpd_sys_content_t ‘/var/www2/html(*./)’
/etc/selinux/targeted/contexts/files/file_contexts.local:  line 13 has invalid regex /var/www2/html(*,/):  Invalid preceding regular expression
/etc/selinux/targeted/contexts/files/file_contexts.local:  line 14 has invalid regex /var/www2/html(*./):  Invalid preceding regular expression

Well crap, its still not correct. So I enter this command and get another error.

#semanage fcontext -a -t httpd_sys_content_t “/var/www2/html(/.*)?

So at this point I start running all sorts of variations of the command with minor syntax changes each time, each time getting an error and each time getting more and more frustrated thinking that I am still not running the command correctly.

However this is not actually the case.

After I take a step back and cool off I actually take the time to read the error message which is pointing me t the file, file_contexts.local. Which upon further inspection actually contains each and every regex that I just ran regardless of the fact that the regex was correct.

# cat /etc/selinux/targeted/contexts/files/file_contexts.local | grep www2
/var/www2    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/,*)?    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/,*)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html    system_u:object_r:httpd_sys_content_t:s0
/var/www2(/.*)?    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(*,/)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(*./)    system_u:object_r:httpd_sys_content_t:s0
/var/www2/html(/.*)?    system_u:object_r:httpd_sys_content_t:s0

In a nutshell.. the semanage command added each and context to file/directory mapping despite the fact that my regex was not correct, and then it gave me an error. So each time I ran the command with the an invalid regex, another entry was added and the error message grew. One would think that it would detect the regex error first and not add it to the file.

Anwyway the fix was to identify all the bad lines in the file from the error message and run the following command against each entry.

#semanage fcontext -d “/var/www2/html(*,/)?”

Once I cleaned out the file of the offending entries I was able to run the command one last time, this time using the correct syntax and was error free

RHEL6 – Using ACLs to Grant and Restrict FIle Access.


Access Control Lists or ACLs provide more controll over file permissions than standard linux file permissions (UGO — user, group, other). For example lets say that you want all members of the group "students" to have the ability to read a file, however you want to allow one user in that group the ability to write to the file, well ACLs can help you do this.

First thing that you need to know is that you cannot just start using ACLs right away, first you have to make sure that your filesystem is mounted so that ACLs are availible. This means adding ACL to the mount options in /etc/fstab.

UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr

So in my fstab, I change the line above to the line below. I know, exciting right?

UUID=3fa4603e-9874-4f47-ae1c-3f7715a54238 /                       ext4    defaults,user_xattr.acl

Now to view the permissions and ACLs on a file use the getfacl command, below i am checking the file RangerRick.jpg in /root/Pictures.  In the example below there are no ACLs assigned, btw.

[root@fedora15 Pictures]# getfacl RangerRick.jpg
# file: RangerRick.jpg
# owner: root
# group: root

So lets allow the user "chris" to write to the file, just just read it.

[root@fedora15 Pictures] setfacl -m u:chris:w RangerRick.jpg

Now run getfacl again and check out the difference

[root@fedora15 Pictures]# getfacl RangerRick.jpg
# file: RangerRick.jpg
# owner: root
# group: root

Additonal Examples:

Lets give all users in the group "students" the ability to write to the file, since they may want to modify it and add a photochop their faces over the dear old racoon's face.

[root@fedora15 Pictures] setfactl -m g:students:w RangerRick.jpg

But oh no, user "bert" in the group "students", has decided to modify the file RangerRick.jpg in an in appropriate way, so lets remove his permissions altogether.

[root@fedora15 Pictures] setfacl -x u:bert

Lets say that we want to allow the user "chris" to be able to modify all existing and newly created files in the Pictures directory where the Ranger Rick picture lives.

[root@fedora15 Pictures] setfacl -m d:u:chris:rw /root/Pictures

Note that when a file has ACLs assigned to it, a plus "+" sign will appear in the output of an 'ls-l'

-rw-rw-r–+ 1 root root 148011 Oct 12 15:06 RangerRick.jpg

Honestly you will probably never need to use ACLs, but they are handy to have availible if you run into some sort of situation where you need to grant very particular permissions to files and directories.