Loading [MathJax]/jax/input/TeX/jax.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >理解 Docker 容器中的 uid 和 gid

理解 Docker 容器中的 uid 和 gid

作者头像
星哥玩云
发布于 2022-07-19 08:27:05
发布于 2022-07-19 08:27:05
7.1K00
代码可运行
举报
文章被收录于专栏:开源部署开源部署
运行总次数:0
代码可运行

默认情况下,容器中的进程以 root 用户权限运行,并且这个 root 用户和宿主机中的 root 是同一个用户。听起来是不是很可怕,因为这就意味着一旦容器中的进程有了适当的机会,它就可以控制宿主机上的一切!本文我们将尝试了解用户名、组名、用户 id(uid)和组 id(gid)如何在容器内的进程和主机系统之间映射,这对于系统的安全来说是非常重要的。说明:本文的演示环境为 Ubuntu 16.04(下图来自互联网)。

先来了解下 uid 和 gid

uid 和 gid 由 Linux 内核负责管理,并通过内核级别的系统调用来决定是否应该为某个请求授予特权。比如当进程试图写入文件时,内核会检查创建进程的 uid 和 gid,以确定它是否有足够的权限修改文件。注意,内核使用的是 uid 和 gid,而不是用户名和组名。 简单起见,本文中剩下的部分只拿 uid 进行举例,系统对待 gid 的方式和 uid 基本相同。

很多同学简单地把 docker 容器理解为轻量的虚拟机,虽然这简化了理解容器技术的难度但是也容易带来很多的误解。事实上,与虚拟机技术不同:同一主机上运行的所有容器共享同一个内核(主机的内核)。容器化带来的巨大价值在于所有这些独立的容器(其实是进程)可以共享一个内核。这意味着即使由成百上千的容器运行在 docker 宿主机上,但内核控制的 uid 和 gid 则仍然只有一套。所以同一个 uid 在宿主机和容器中代表的是同一个用户(即便在不同的地方显示了不同的用户名)。 注意,由于普通的用来显示用户名的 Linux 工具并不属于内核(比如 id 等命令),所以我们可能会看到同一个 uid 在不同的容器中显示为不同的用户名。但是对于相同的 uid 不能有不同的特权,即使在不同的容器中也是如此。

如果你已经了解了 Linux 的 user namespace 技术,参考《Linux Namespace : User》,你需要注意的是到目前为止,docker 默认并没有启用 user namesapce,这也是本文讨论的情况。笔者会在接下来的文章中介绍如何配置 docker 启用 user namespace。

容器中默认使用 root 用户

如果不做相关的设置,容器中的进程默认以 root 用户权限启动,下面的 demo 使用 ubuntu 镜像运行 sleep 程序:

$ docker run -d  --name sleepme ubuntu sleep infinity

注意上面的命令中并没有使用 sudo。笔者在宿主机中的登录用户是 nick,uid 为 1000:

在宿主机中查看 sleep 进程的信息:

$ ps aux | grep sleep

sleep 进程的有效用户名称是 root,也就是说 sleep 进程具有 root 权限。 然后进入容器内部看看,看到的情况和刚才一样,sleep 进程也具有 root 权限:

那么,容器内的 root 用户和宿主机上的 root 用户是同一个吗? 答案是:是的,它们对应的是同一个 uid。原因我们在前面已经解释过了:整个系统共享同一个内核,而内核只管理一套 uid 和 gid。

其实我们可以通过数据卷来简单的验证上面的结论。在宿主机上创建一个只有 root 用户可以读写的文件:

然后挂载到容器中:

dockerrunrmitw=/testvv(pwd)/testv:/testv ubuntu

在容器中可以读写该文件:

我们可以通过 Dockerfile 中的 USER 命令或者是  docker run 命令的 --user 参数指定容器中进程的用户身份。下面我们分别来探究这两种情况。

在 Dockerfile 中指定用户身份

我们可以在 Dockerfile 中添加一个用户 appuser,并使用 USER 命令指定以该用户的身份运行程序,Dockerfile 的内容如下:

FROM ubuntu RUN useradd -r -u 1000 -g appuser USER appuser ENTRYPOINT ["sleep", "infinity"]

编译成名称为 test 的镜像:

$ docker build -t test .

用 test 镜像启动一个容器:

$ docker run -d --name sleepme test

在宿主机中查看 sleep 进程的信息:

这次显示的有效用户是 nick,这是因为在宿主机中,uid 为 1000 的用户的名称为 nick。再进入到容器中看看:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
$ docker exec -it sleepme bash

容器中的当前用户就是我们设置的 appuser,如果查看容器中的 /etc/passwd 文件,你会发现 appuser 的 uid 就是 1000,这和宿主机中用户 nick 的 uid 是一样的。

让我们再创建一个只有用户 nick 可以读写的文件:

同样以数据卷的方式把它挂载到容器中:

dockerrundnamesleepmew=/testvv(pwd)/testv:/testv test

在容器中 testfile 的所有者居然变成了 appuser,当然 appuser 也就有权限读写该文件。

这里到底发生了什么?而这些又这说明了什么? 首先,宿主机系统中存在一个 uid 为 1000 的用户 nick。其次容器中的程序是以 appuser 的身份运行的,这是由我们通过 USER appuser 命令在 Dockerfile 程序中指定的。 事实上,系统内核管理的 uid 1000 只有一个,在宿主机中它被认为是用户 nick,而在容器中,它则被认为是用户 appuser。 所以有一点我们需要清楚:在容器内部,用户 appuser 能够获取容器外部用户 nick 的权利和特权。在宿主机上授予用户 nick 或 uid 1000 的特权也将授予容器内的 appuser。

从命令行参数中自定用户身份

我们还可以通过 docker run 命令的 --user 参数指定容器中进程的用户身份。比如执行下面的命令:

$ docker run -d --user 1000 --name sleepme ubuntu sleep infinity

因为我们在命令行上指令了参数 --user 1000,所以这里 sleep 进程的有效用户显示为 nick。进入到容器内部看一下:

$ docker exec -it sleepme bash

这是个什么情况?用户名称居然显示为 "I have no name!"!去查看 /etc/passwd 文件,里面果然没有 uid 为 1000 的用户。即便没有用户名称,也丝毫不影响该用户身份的权限���它依然可以读写只有 nick 用户才能读写的文件,并且用户信息也由 uid 代替了用户名:

需要注意的是,在创建容器时通过 docker run --user 指定的用户身份会覆盖掉 Dockerfile 中指定的值。 我们重新通过 test 镜像来运行两个容器:

$ docker run -d test

查看 sleep 进程信息:

$ docker run --user 0 -d test

再次查看 sleep 进程信息:

指定了 --urser 0 参数的进程显示有效用户为 root,说明命令行参数 --user 0 覆盖掉了 Dockerfile 中 USER 命令的设置。

总结

从本文中的示例我们可以了解到,容器中运行的进程同样具有访问主机资源的权限(docker 默认并没有对用户进行隔离),当然一般情况下容器技术会把容器中进程的可见资源封锁在容器中。但是通过我们演示的对数据卷中文件的操作可以看出,一旦容器中的进程有机会访问到宿主机的资源,它的权限和宿主机上用户的权限是一样的。所以比较安全的做法是为容器中的进程指定一个具有合适权限的用户,而不要使用默认的 root 用户。当然还有更好的方案,就是应用 Linux 的 user namespace 技术隔离用户,笔者会在接下来的文章中介绍如何配置 docker 开启 user namespace 的支持。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
理解 Docker 容器中 UID 和 GID 的工作原理
理解用户名、组名、用户ID(UID)和组ID(GID)在容器内运行的进程与主机系统之间的映射是构建安全系统的重要一环。如果没有提供其他选项,容器中的进程将以root用户身份执行(除非在Dockerfile中提供了不同的UID)。本文将解释这一工作原理,如何正确授予权限,并提供示例加以说明。
用户1107783
2024/03/18
6900
理解 Docker 容器中 UID 和 GID 的工作原理
docker挂载volume的用户权限问题,理解docker容器的uid
在刚开始使用docker volume挂载数据卷的时候,经常出现没有权限的问题。 这里通过遇到的问题来理解docker容器用户uid的使用,以及了解容器内外uid的映射关系。
Ryan-Miao
2019/08/05
14.5K0
docker挂载volume的用户权限问题,理解docker容器的uid
隔离 Docker 容器中的用户
笔者在前文《理解 docker 容器中的 uid 和 gid》介绍了 docker 容器中的用户与宿主机上用户的关系,得出的结论是:docker 默认没有隔离宿主机用户和容器中的用户。如果你已经了解了 Linux 的 user namespace 技术(参考《Linux Namespace : User》),那么自然会问:docker 为什么不利用 Linux user namespace 实现用户的隔离呢?事实上,docker 已经实现了相关的功能,只是默认没有启用而已。笔者将在本文中介绍如何配置 docker 来隔离容器中的用户。 说明:本文的演示环境为 Ubuntu 16.04。
星哥玩云
2022/07/19
3.7K1
隔离 Docker 容器中的用户
Docker速学(三) 网络、用户和进程
在前文,我们介绍了Docker学习的基本方法和原理,以及基础三大件:镜像、容器、仓库。还有Dockerfile和数据卷。
w9
2021/08/27
5710
浅析Docker运行安全
AppArmor 主要的作用是设置某个可执行程序的访问控制权限,可以限制程序 读/写某个目录/文件,打开/读/写网络端口等等。
FB客服
2020/04/18
3K0
在docker容器中使用非root用户执行脚本 (
应用容器化之后,在docker容器启动时,默认使用的是root用户执行命令,因此容器中的应用默认都是使用root用户来运行的,存在很高的安全风险,那么如何能够使用非root的业务用户来运行应用呢,下面我将举一个简单的例子来说明。该例子是在容器中使用自建的用户来运行一个简单的shell脚本,并将脚本输出日志持久到容器外部。接下来让我们来看从制作镜像到容器运行的全过程吧。 1、构建镜像: 我将会使用dockerfile的方式来构建镜像,基础镜像使用ubuntu 14.04(需要先拉取该镜像,docker pull ubuntu:14.04)。dockerfile内容如下 [root@host09 test]# cat Dockerfile FROM docker.io/ubuntu:14.04   MAINTAINER hepengfei RUN groupadd hpf  --创建用户组 RUN useradd -d /data -g hpf -m hpf   --创建用户 RUN su - hpf -c "mkdir -p /data/scripts"  RUN su - hpf -c "mkdir -p /data/logs" WORKDIR /data/scripts COPY test.sh /data/scripts/ RUN chown hpf:hpf test.sh RUN chmod 755 test.sh ENTRYPOINT su - hpf -c "/data/scripts/test.sh" --使用所创建的用户来运行脚本 [root@host09 test]#
双面人
2019/10/24
2.3K0
DockerFile就这么简单
当我们在使用docker时,最重要的就是镜像,只要有了镜像,我们就可以随时随地的根据镜像来创建一个容器,从而做到让我们的服务可以在任何时间任何地点任何环境下运行起来。那么镜像是怎么制作的呢?总体来讲,制作镜像有两种方法:
后场技术
2020/09/03
1.8K0
DockerFile就这么简单
Docker 容器镜像制作指令详解
从镜像大小上面来说,一个比较小的镜像只有1MB多点或几MB,而内核文件需要几十MB, 因此镜像里面是没有内核的,镜像在被启动为容器后将直接使用宿主机的内核,而镜像本身则只提供相应的rootfs,即系统正常运行所必须的用户空间的文件系统,比如: /dev/,/proc,/bin,/etc等目录,容器当中/boot目录是空的,而/boot当中保存的就是与内核相关的文件和目录。
BUG弄潮儿
2022/06/07
3.4K0
Docker 容器镜像制作指令详解
如何提升docker容器安全性
原创文章,转载请务必将下面这段话置于文章开头处。 本文转发自:字母哥博客,原文链接 http://www.zimug.com/463.html
字母哥博客
2020/09/23
1.1K0
打开云原生大门:了解Linux命名空间的奥秘和Docker容器隔离技术
RootFS (Root File System),即根文件系统,是 Docker 容器启动时内部进程所能感知到的整个文件系统结构的起点,可以简单理解为 Docker 容器的根目录。 它是容器运行环境的基础,承载着容器运行所需的一切资源。
Lion 莱恩呀
2025/05/02
1330
打开云原生大门:了解Linux命名空间的奥秘和Docker容器隔离技术
6.Docker镜像与容器安全最佳实践
描述: 在企业中信息系统安全与业务是同样重要, 随着传统运维方式向着容器化运维方式的转变,当下企业里通常都会采用Docker来进行容器化部署和承载业务, 由于运维人员或者开发人员对容器安全的关注较少, 只是简单认为容器是有隔离和限制的, 就算是容器被黑客攻击了, 也单单是容器内部受到影响, 而对宿主的 Linux 系统和网络都不会产生太大影响。其实不然Docker容器安全也是重中之重, 它关乎着应用与数据安全,其中也关乎着宿主机的安全。
全栈工程师修炼指南
2022/09/28
3.4K0
6.Docker镜像与容器安全最佳实践
【随笔小记】提高Docker容器的安全性
随着 Docker 的兴起,越来越多的项目采用 Docker 搭建生产环境,因为容器足够轻量化,可以快速启动并且迁移业务服务,不过在使用的过程中,我们很容易就忽略了项目的安全问题,容器虽然有隔离的作用,但是我们知道,他与虚拟机的架构差距还是比较大的。
Balliol Chen
2022/04/21
6170
Docker容器安全性分析
Docker是目前最具代表性的容器技术之一,对云计算及虚拟化技术产生了颠覆性的影响。本文对Docker容器在应用中可能面临的安全问题和风险进行了研究,并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析。
FB客服
2019/12/23
2.1K0
Docker容器安全性分析
如何 10 步 Docker 化一个应用?
网上大多数教程使用的都是以 Ubuntu(例如:Ubuntu:16.04 )作为基础镜像,这并不是一个问题,但是我建议优先考虑 Alpine 镜像:
用户6543014
2019/10/25
7850
理解OpenShfit(5):从 Docker Volume 到 OpenShift Persistent Volume
理解OpenShift(5):从 Docker Volume 到 OpenShift Persistent Volume
SammyLiu
2019/06/28
1.7K0
理解OpenShfit(5):从 Docker Volume 到 OpenShift Persistent Volume
应该了解的 10 个 Kubernetes 安全上下文配置
在 Kubernetes 中安全地运行工作负载是很困难的,有很多配置都可能会影响到整个 Kubernetes API 的安全性,这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具 securityContext,每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种 securityContext 的配置,探讨它们的含义,以及我们应该如何使用它们。
我是阳明
2021/04/26
2.2K0
应该了解的 10 个 Kubernetes 安全上下文配置
容器逃逸成真:从CTF解题到CVE-2019-5736漏洞挖掘分析
35C3 CTF是在第35届混沌通讯大会期间,由知名CTF战队Eat, Sleep, Pwn, Repeat于德国莱比锡举办的一场CTF比赛。比赛中有一道基于Linux命名空间机制的沙盒逃逸题目。赛后,获得第三名的波兰强队Dragon Sector发现该题目所设沙盒在原理上与docker exec命令所依赖的runc(一种容器运行时)十分相似,遂基于题目经验对runc进行漏洞挖掘,成功发现一个能够覆盖宿主机runc程序的容器逃逸漏洞。该漏洞于2019年2月11日通过邮件列表披露,分配编号CVE-2019-5736。
绿盟科技研究通讯
2019/12/11
3.6K0
容器逃逸成真:从CTF解题到CVE-2019-5736漏洞挖掘分析
浅谈日常使用的 Docker 底层原理-三大底座
适合的读者,对Docker有过简单了解的朋友,想要进一步了解Docker容器的朋友。
宁在春
2023/10/16
1.9K0
浅谈日常使用的 Docker 底层原理-三大底座
善攻者,动于九天之上。你的容器安全吗?
大家好,我是二哥。从今天开始的几篇,我会集中聊聊与容器安全相关的内容。我粗略估计会涉及到user account、capability、container image、container isolation的加固、container isolation的破防、container network security(涉及到网路安全,不是网络方案)、container runtime security等方面的内容。
LanceZhang
2021/12/06
4700
善攻者,动于九天之上。你的容器安全吗?
Docker安全入门与实战(四)
众所周知,Docker使用namespace进行环境隔离、使用cgroup进行资源限制。但是在实际应用中,还是有很多企业或者组织没有使用namespace或者cgroup对容器加以限制,从而埋下安全隐患。本文定位于简单介绍namespace和cgroup的基本原理之后,通过具体配置和应用向读者展示如何应用这些技术保护docker容器安全,不过namespace和cgroup并不是万能的,他们只是保障Docker容器安全的多种方案中的一类而已。
0xtuhao
2022/06/21
3840
推荐阅读
相关推荐
理解 Docker 容器中 UID 和 GID 的工作原理
更多 >
交个朋友
加入腾讯云官网粉丝站
蹲全网底价单品 享第一手活动信息
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档