容器挂载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检查失败,查看本地文件策略如下:
[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
TIPs:
- 使用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
本文来自博客园,作者:charlieroro,转载请注明原文链接:https://www.cnblogs.com/charlieroro/p/9491159.html