svn 检出后的 SELinux fcontext
SELinux fcontext after svn checkout
首先我想告诉大家，没有真正的问题，一切都按我预期的那样工作，但是我遇到了一种我无法解释的奇怪行为，所以我想从更有经验的工程师那里寻求一些见解。
观察到 SELinux 如何应用 fcontext 映射定义的奇怪行为。
让我先打印适用于我的案例的 SELinux fcontext 策略：
[root@ip-10-0-0-40 wp-content]# semanage fcontext -l | grep "^/var/www.*httpd_sys_rw_content_t:s0\s$"
/var/www/svn(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/files(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/settings\.php regular file system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/moodledata(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/moodle/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/gallery/albums(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html/owncloud/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0
从命令中可以看出，我对使httpd能够写入内部的fcontext策略感兴趣/var/www.
我正在设置 WordPress 安装，所以我的目光锁定在这些政策上：
/var/www/html(/.*)?/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
根据策略 RegExp，我可以确定我需要的目录结构。让我们为项目创建一个目录并结帐。
[root@ip-10-0-0-40 /]# mkdir -p /var/www/html/sun
[root@ip-10-0-0-40 /]# cd /var/www/html/sun
[root@ip-10-0-0-40 sun]# svn co http://server/ .
让我们检查一下我们是否应用了正确的 fcontext：
[root@ip-10-0-0-40 sun]# cd /var/www/html/sun/public/wp-content
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
太棒了！只是为了兴趣和仔细检查，让我们尝试恢复 fcontext 看看会发生什么：
[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/html/sun/
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
太棒了！按预期工作。
为了完成测试，让我们模拟一个预期的失败。让我们在 /html/ 之外创建一个项目目录，如下所示：/var/www/sun 和 checkout.
[root@ip-10-0-0-40 wp-content]# mkdir -p /var/www/sun
[root@ip-10-0-0-40 wp-content]# cd /var/www/sun/
[root@ip-10-0-0-40 sun]# svn co http://server/ .
让我们检查一下我们是否应用了正确的 fcontext：
[root@ip-10-0-0-40 sun]# cd /var/www/sun/public/wp-content/
[root@ip-10-0-0-40 wp-content]# ls –Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
奇怪，我期待看到httpd_sys_content_t（默认fcontext），让我们尝试恢复到默认：
[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/sun
...Output omitted
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 uploads
对 /var/www/sun 使用 restorecon 可以正常工作，但是……谜题是：
为什么/var/www/sun里面的svn co使用了不存在的策略？策略匹配 fcontext 但不匹配此位置：
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
以及 index.php 有不同的 fcontext，但是目录有相同的：httpd_sys_rw_content_t
我有同样的问题，"Why are wp-content directories automatically labelled with httpd_sys_rw_content_t even outside of the fcontext rules for /var/www/html ?"。不过，我现在找到了答案，我想我会 post 在这里。
这是由 SELinux 的一项称为文件名转换的功能引起的，该功能是一种帮助创建正确标记的文件和目录的策略机制。
在您的示例中，目录 /var/www/sun/public 继承自 httpd_sys_content_t/var/www.
通常，在 /var/www/sun/public 中创建的名为 wp-content 的目录也会继承 httpd_sys_content_t.
但是在 apache.if 中有一个文件名转换规则，它表示任何名为 "wp-content" 的目录都可以使用 创建httpd_sys_content_t 应该创建为 httpd_sys_rw_content_t
在CentOS 7中，安装selinux-policy-devel包，可以看到/usr/share/selinux/devel/include/contrib/apache.if中的定义
filetrans_pattern(, httpd_sys_content_t, httpd_sys_rw_content_t, dir, "wp-content")
您可以通过以下方式测试理论：
[root@dt-laptop-centos7 /]# mkdir junk
[root@dt-laptop-centos7 /]# ls -aldZ junk
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 junk
[root@dt-laptop-centos7 /]# chcon -t httpd_sys_content_t junk
[root@dt-laptop-centos7 /]# ls -aldZ junk
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 junk
[root@dt-laptop-centos7 /]# cd junk
[root@dt-laptop-centos7 junk]# mkdir wp-otherdir
[root@dt-laptop-centos7 junk]# mkdir wp-content
[root@dt-laptop-centos7 junk]# ls -alZ
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0 ..
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 wp-otherdir
您可以看到 wp-content 的上下文自动设置为 httpd_sys_rw_content_t 而 wp -otherdir 只是继承了 httpd_sys_content_t
首先我想告诉大家，没有真正的问题，一切都按我预期的那样工作，但是我遇到了一种我无法解释的奇怪行为，所以我想从更有经验的工程师那里寻求一些见解。
观察到 SELinux 如何应用 fcontext 映射定义的奇怪行为。
让我先打印适用于我的案例的 SELinux fcontext 策略：
[root@ip-10-0-0-40 wp-content]# semanage fcontext -l | grep "^/var/www.*httpd_sys_rw_content_t:s0\s$"
/var/www/svn(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/files(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/sites/default/settings\.php regular file system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/moodledata(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/moodle/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/gallery/albums(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html/owncloud/data(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html/configuration\.php all files system_u:object_r:httpd_sys_rw_content_t:s0
从命令中可以看出，我对使httpd能够写入内部的fcontext策略感兴趣/var/www.
我正在设置 WordPress 安装，所以我的目光锁定在这些政策上：
/var/www/html(/.*)?/uploads(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
根据策略 RegExp，我可以确定我需要的目录结构。让我们为项目创建一个目录并结帐。
[root@ip-10-0-0-40 /]# mkdir -p /var/www/html/sun
[root@ip-10-0-0-40 /]# cd /var/www/html/sun
[root@ip-10-0-0-40 sun]# svn co http://server/ .
让我们检查一下我们是否应用了正确的 fcontext：
[root@ip-10-0-0-40 sun]# cd /var/www/html/sun/public/wp-content
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
太棒了！只是为了兴趣和仔细检查，让我们尝试恢复 fcontext 看看会发生什么：
[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/html/sun/
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
太棒了！按预期工作。
为了完成测试，让我们模拟一个预期的失败。让我们在 /html/ 之外创建一个项目目录，如下所示：/var/www/sun 和 checkout.
[root@ip-10-0-0-40 wp-content]# mkdir -p /var/www/sun
[root@ip-10-0-0-40 wp-content]# cd /var/www/sun/
[root@ip-10-0-0-40 sun]# svn co http://server/ .
让我们检查一下我们是否应用了正确的 fcontext：
[root@ip-10-0-0-40 sun]# cd /var/www/sun/public/wp-content/
[root@ip-10-0-0-40 wp-content]# ls –Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 uploads
奇怪，我期待看到httpd_sys_content_t（默认fcontext），让我们尝试恢复到默认：
[root@ip-10-0-0-40 wp-content]# restorecon -Rv /var/www/sun
...Output omitted
[root@ip-10-0-0-40 wp-content]# ls -Z
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.php
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 languages
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 mu-plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 plugins
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 themes
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 uploads
对 /var/www/sun 使用 restorecon 可以正常工作，但是……谜题是：
为什么/var/www/sun里面的svn co使用了不存在的策略？策略匹配 fcontext 但不匹配此位置：
/var/www/html(/.*)?/wp-content(/.*)? all files system_u:object_r:httpd_sys_rw_content_t:s0
以及 index.php 有不同的 fcontext，但是目录有相同的：httpd_sys_rw_content_t
我有同样的问题，"Why are wp-content directories automatically labelled with httpd_sys_rw_content_t even outside of the fcontext rules for /var/www/html ?"。不过，我现在找到了答案，我想我会 post 在这里。
这是由 SELinux 的一项称为文件名转换的功能引起的，该功能是一种帮助创建正确标记的文件和目录的策略机制。
在您的示例中，目录 /var/www/sun/public 继承自 httpd_sys_content_t/var/www.
通常，在 /var/www/sun/public 中创建的名为 wp-content 的目录也会继承 httpd_sys_content_t.
但是在 apache.if 中有一个文件名转换规则，它表示任何名为 "wp-content" 的目录都可以使用 创建httpd_sys_content_t 应该创建为 httpd_sys_rw_content_t
在CentOS 7中，安装selinux-policy-devel包，可以看到/usr/share/selinux/devel/include/contrib/apache.if中的定义
filetrans_pattern(, httpd_sys_content_t, httpd_sys_rw_content_t, dir, "wp-content")
您可以通过以下方式测试理论：
[root@dt-laptop-centos7 /]# mkdir junk
[root@dt-laptop-centos7 /]# ls -aldZ junk
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 junk
[root@dt-laptop-centos7 /]# chcon -t httpd_sys_content_t junk
[root@dt-laptop-centos7 /]# ls -aldZ junk
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 junk
[root@dt-laptop-centos7 /]# cd junk
[root@dt-laptop-centos7 junk]# mkdir wp-otherdir
[root@dt-laptop-centos7 junk]# mkdir wp-content
[root@dt-laptop-centos7 junk]# ls -alZ
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0 ..
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content
drwxr-xr-x. root root unconfined_u:object_r:httpd_sys_content_t:s0 wp-otherdir
您可以看到 wp-content 的上下文自动设置为 httpd_sys_rw_content_t 而 wp -otherdir 只是继承了 httpd_sys_content_t