使用如下系統(centos)運行容器后，在容器內的掛載目錄內執行ls命令出現了“Permission denied”的錯誤
Linux localhost.localdomain 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
容器運行命令如下，將/home/centosDir掛載到容器容器的/home目錄
docker run -v /home/centosDir/:/home -it -d --name=centos 49f7960eb7e4 /bin/bash
出現“Permission denied”的問題，首先懷疑是/home/centosDir的讀寫權限不夠，直接修改為777之后仍然出現“Permission denied”的錯誤。經過查找解決方法如下，即修改host掛載目錄的MAC權限：
chcon -Rt svirt_sandbox_file_t /home/centosDir
centos啟用了SUSE的安全功能，目錄權限除了一般的DAC訪問控制外，還啟動了MAC訪問控制。DAC即一般的ugo+rwx，可以使用chmod，chown，chgrp來改變其文件/目錄權限。MAC為在DAC之上的訪問控制，即如果訪問權限沒有通過DAC檢查，則直接訪問失敗；否則繼續MAC訪問權限檢查
查看原始容器內掛載的目錄/home的MAC如下，/home的type與容器不匹配，導致MAC檢查失敗，查看本地文件策略如下：
[root@localhost overlay2]# ls -Z /home/ drwxr-xr-x. root root unconfined_u:object_r:user_home_dir_t:s0 centosDir drwx------. charlie charlie unconfined_u:object_r:user_home_dir_t:s0 charlie
使用docker inspect centos查看容器的文件策略，如下，可以看到容器需要的掛載類型為svirt_sandbox_file_t，進程運行域為svirt_lxc_net_t，因此解決方法為將掛載文件修改為與容器需要的類型一樣即可
"MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c161,c568", "ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c161,c568",
使用chcon -Rt svirt_sandbox_file_t /home/centosDir修改后，MAC變為如下(主要是type字段)，這樣就可以正常訪問了：
[root@cfd98c17be4b /]# ls -Z /
lrwxrwxrwx. root root system_u:object_r:container_file_t:s0:c268,c731 bin -> usr/bin
drwxr-xr-x. root root system_u:object_r:container_file_t:s0:c268,c731 dev
drwxr-xr-x. root root system_u:object_r:container_file_t:s0:c268,c731 etc
drwxr-xr-x. root root unconfined_u:object_r:container_file_t:s0 home
MAC了解：
啟用MAC的配置文件在/etc/selinux/config下，可以看到一條配置：SELINUX=enforcing，也可以使用sestatus查看當前狀態
[root@localhost selinux]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 31
只要SELinux的工作模式是Enforcing，根據SELinux所選擇的策略結果集，給所有文件和進程都打上安全標簽，即：安全上下文（security context）。這一行為是在將SELinux的模式由disabled模式更改為enforcing模式后的第一次啟動時完成的.
不同的進程只在自己所屬的域內運行，運行在域中的進程只對授權的類型具有讀寫權限，強制訪問控制的標准是基於程序的域類型而不是基於用戶的域類型
默認情況下，Linux用戶是非限制的，對於非限制的進程(非限制的用戶運行在 unconfined_t 域中)， SELinux 的策略規則仍然適用，然而有關允許進程運行在非限制域的規則幾乎允許所有的訪問。此時，相當於 SELinux 不起作用
安全上下文有五個元素組成，以冒號分隔
user:role:type:sensitivity:category
User:指示登錄系統的用戶類型,如root,user_u,system_u,多數本地進程都屬於自由（unconfined）進程
Role:定義文件，進程和用戶的用途：文件:object_r，進程和用戶：system_r
Type:指定數據類型，規則中定義何種進程類型訪問何種文件Target策略基於type實現,多服務共用：public_content_t
Sensitivity:限制訪問的需要，由組織定義的分層安全級別，如unclassified, secret,top,secret, 一個對象有且只有一個sensitivity,分0-15級，s0最低,Target策略默認使用s0
Category：對於特定組織划分不分層的分類，如FBI Secret，NSA secret, 一個對象可以有多個categroy， c0-c1023共1024個分類， Target 策略不使用category
使用chcon修改安全上下文，使用restorecon恢復目錄或文件默認的安全上下文，使用semanage可以為端口添加訪問控制
參考：
http://blog.51cto.com/zhaotianyu/1817939
https://yq.aliyun.com/articles/486704?spm=5176.10695662.1996646101.searchclickresult.312d10b5HpsmDH
http://cn.linux.vbird.org/linux_basic/0440processcontrol_5.php#mac
http://jiayu0x.com/2014/12/24/Linux-authority-and-access-control-2/
http://www.cse.psu.edu/~trj1/cse543-f07/slides/03-PolicyConcepts.pdf
http://www.informit.com/articles/article.aspx?p=606586&seqNum=2