【轉】容器掛載volume出現“Permission denied”的問題定位解決
使用如下系統(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檢查失敗，檢視本地檔案策略如下：
[[email protected] 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欄位)，這樣就可以正常訪問了：
[[email protected] /]# 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檢視當前狀態
[[email protected] 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