Docker 相同GID对应不同用户组导致的无权限问题

关于架构

  • PHP7.2
  • OpenResty
  • Redis
  • MySQL

上面的架构在Linux中有个非常常见的名字是LNMP。基本上是在相同的系统中进行的配置。因此,常规的业务中几乎不会有人会在LNMP这架构上遇到标题中的问题。

但是在Docker中,可以有PHP环境是Debian,OpenResty环境是alpine这样的搭配。

验证无权限问题

拉取Debian 9.2的镜像 docker pull debian:9.2,然后运行 docker run 6d83de432e98 ping baidu.com。进入系统中查看用户分组 cat /etc/group

上面就是debian镜像中的所有分组。

然后拉取apline 3.6 的镜像 docker pull alpine:3.6,并运行docker run 77144d8c6bdc ping baidu.com。进入系统查看用户分组

在Debian系统中用www-data用户组中www-data用户跑php服务。产生一个socket文件 php7.sock 代替端口监听。这个文件被挂载到宿主机的目录上。OpenResty通过挂载目录到相同的宿主机目录上来设置监听。

通过编写编排文件docker-compose.yml文件,运行docker-compose up进行部署服务。php服务中会给php7.sock文件赋予 swr-wr----的权限,而该文件所属www-data:www-data。此时就会出现一个问题。在Debian中,该文件是www-data这个组中的用户可以读写的,但是在alpine中并没有这个www-data的用户组和这个用户。那他是怎么处理这个问题的呢?(在linux中的文件,是不可能没有所属用户和所属用户组的。) 观察Debian中的www-data的用户组列表,发现该组中的编号是33。在实际操作部署中,php7.sock文件是属于xfs:xfs,而Debian中的www-data的GID正好与alpine中的xfs的GID相同。

GID相同造成两个系统中的授权出现了不同,而(矫情的)sock文件只认www-data这个用户组中的用户,因此造成了OpenResty在有请求时监听sockt文件会出现没有权限读取的问题。

解决问题

既然docker跨系统的授权是通过GID配对,而sockt文件只认同名字用户组用户。因此需要删除xfs用户组创建www-data用户组。

编排代码

相关git:https://gitee.com/jinfeijie/dockerService

Leave a Reply

Your email address will not be published. Required fields are marked *