SELinux issues (1)

SELinux, most distributions are activated by default, the importance of security, but there is some complexity in itself, unfamiliar prone to produce some inexplicable problems.

Getenforce

Sestatus View selinux Status

Setenforce 0/1 temporarily modified SELinux status, restart failure

Cd/etc/selinux/config

Selinux=enforcing/disabled after reboot, permanent

Instance:

We also need to confirm that the system has been installed and started Apache, no, yum to install one, it is very simple, not much to say, and then in the root directory to create a test file test.html, as follows:

shell> cat/root/test.html Hello, world.

Then copy this test file to the Apache DocumentRoot directory, my Apache is installed through Yum, the default is the/var/www/html directory, as follows:

Shell> cp/root/test.html/var/www/html

Then, if there are no moths, everything should be expected, as follows:

Shell> Curl http://localhost/test.html Hello, world.

See this, you may think I am a nonsense, do not worry, the following is the time to witness the miracle:

Also the test file test.html, but this time is no longer a copy, but moving, as follows:

Shell> mv/root/test.html/var/www/html

go on, what, the result is very surprising, unexpectedly prompt permission error, as follows:

Of course, we now know that this problem is caused by selinux, but we do not know why, in fact, the cause of the problem is now recorded in the corresponding log audit process, you can view:

Shell> audit2why </var/log/audit/audit.log

If you do not understand, it is recommended to install the Setroubleshoot kit:

shell> Yum Install Setroubleshoot

It is a GUI suite in itself, but it contains a sealert command that is useful to our command-line users:

Shell> sealert -a /var/log/audit/audit.log  summary:   SELinux is  preventing /usr/sbin/httpd  "GetAttr"  access to  /var/www/html/test.html.   detailed description:   SELinux denied access requested by  Httpd. /var/www/html/test.html may be a  mislabeled. /var/www/html/test.html  default selinux type is httpd_sys_content_t,  but its current  Type is admin_home_t. changing this file back to the default  type, may fix your problem.   File contexts can be assigned to a file in the  Following ways.     * Files created in a directory receive the  File context of the parent      directory by default.    * The SELinux policy might override the default  Label inherited from the      parent directory by  Specifying a process running in context a which creates       a file in a directory labeled B will instead  Create the file with label c.      an example of  this would be the dhcp client running with the dhclient_t  type      and creating a file in the directory  /etc. this file would normally receive      the  Etc_t type due to parental inheritance but instead the filE is labeled      with the net_conf_t type because  The selinux policy specifies this.    * users can change the file context on a file  using tools such as chcon, or      restorecon.   This file could have been mislabeled either by user  Error, or if an normally  confined application was run under  The wrong domain.   However, this might also indicate a bug in SELinux  Because the file should not  have been labeled with this type .   if you believe this is a bug, please file a bug  report against this packAge.   allowing access:   You can restore the default system  Context to this file by executing the  restorecon command.  restorecon  '/var/www/html/test.html ',  if this file is a  directory, you  can recursively restore using restorecon -r   '/var/www/html/test.html '.   fix command:   /sbin/restorecon  '/var/www/html/test.html '  

It should be understood this time! The reason is that Apache under the file context type should be httpd_sys_content_t, but now is admin_home_t, so the permissions are wrong, and at the end of the repair command is given.

What do you think of httpd_sys_content_t,admin_home_t? It is simple to use the-Z parameter of the LS command:

Shell> Ls-z/path

Back to the beginning of the problem, the copy did not appear to be the problem because the CP automatically modifies the context property, and the move is problematic because the MV retains the context properties of the original file.

Note: For more information about SELinux and Apache, refer to "Man Httpd_selinux".

Know how to solve the selinux problem, if you encounter similar situation in the future do not rush to arbitrarily shut down selinux.

Similar to before Yum installed MARIADB, the default path/var/lib/mysql, modify the database path to/DATA/MARIADB, in/ETC/MY.CNF also modify the relevant configuration, permissions, owner has been modified, but restart MARIADB failed, is also limited by SELinux. But the other way, from the new initialization mariadb:/usr/libexec/mysqld--basedir=/usr--datadir=/data/mariadb--plugin-dir=/usr/lib64/mysql/ Plugin--log-error=/data/mariadb/log/mariadb.log--pid-file=/var/run/mariadb/mariadb.pid--socket=/data/mariadb/ Mysql.sock

SELinux issues (1)