docker 镜像中的uid

在Docker镜像中，UID（用户标识符）的具体数值并不是固定的，它取决于镜像的构建方式和构建时指定的用户配置。以下是对Docker镜像中UID的详细解释：

UID的分配

• 基础镜像：当从一个基础镜像（如Ubuntu、CentOS等）构建新的Docker镜像时，该基础镜像中已经存在的用户和组会被继承到新镜像中。这些用户和组的UID和GID（组标识符）与基础镜像中的设置保持一致。
• 自定义用户：在Dockerfile中，可以使用useradd或adduser命令添加新用户，并通过-u选项指定该用户的UID。如果没有明确指定，系统会自动为该用户分配一个未被使用的UID。

UID的作用

• 权限控制：在Linux系统中，UID用于确定用户的权限。不同的UID对应不同的用户权限，从而实现对文件和目录的访问控制。
• 进程标识：在Docker容器中运行的进程也会有一个UID。这个UID决定了进程在容器内部和主机系统上的权限。

UID的修改

• 构建时修改：在Dockerfile中，可以使用usermod命令修改已有用户的UID。例如，RUN usermod -u new_uid old_username命令将把名为old_username的用户的UID修改为new_uid。
• 运行时修改：在运行中的容器中，也可以通过usermod命令修改用户的UID。但需要注意的是，这种修改只会在当前运行的容器中生效，不会影响镜像本身。

注意事项

• 避免冲突：在不同的容器中，不应使用相同的UID分配给不同的用户。因为Linux内核统一管理UID和GID空间，相同的UID在不同容器中会映射到相同的用户权限。
• 安全性：为了增强容器的安全性，建议避免以root用户身份运行容器中的进程。可以通过在Dockerfile中指定非root用户或使用--user选项在运行时指定用户来实现这一点。

综上所述，Docker镜像中的UID是一个可变值，它取决于镜像的构建方式和构建时指定的用户配置。因此，无法给出一个固定的UID值来代表所有Docker镜像中的用户。

在Docker中使用自定义UID/GID运行Jenkins

https://bestsrc.com/?p=3625

FROM jenkins/jenkins:latest

ARG uid=1003

ARG gid=1003

USER root

RUN groupmod -g $gid jenkins && usermod -u $uid -g $gid jenkins

USER jenkins

理解 docker 容器中的 uid 和 gid

https://www.cnblogs.com/sparkdev/p/9614164.html

https://www.cnblogs.com/rongfengliang/p/10544093.html

To start, let’s review how uids and gids are implemented. The linux kernel is responsible for managing the uid and gid space, and it’s kernel-level syscalls that are used to determine if requested privileges should be granted. For example, when a process attempts to write to a file, the uid and gid that created the process are examined by the kernel to determine if it has enough privileges to modify the file. The username isn’t used here, the uid is used.

When running Docker containers on a server, there’s still a single kernel. A huge part of the value that containerization brings is that all of these separate processes can continue to share a single kernel. This means that even on a server that is running Docker containers, the entire world of uids and gids is controlled by a single kernel.

So you can’t have different users with the same uid inside different containers. That’s because the username (and group names) that show up in common linux tools aren’t part of the kernel, but are managed by external tools (/etc/passwd, LDAP, Kerberos, etc). So, you might see different usernames, but you can’t have different privileges for the same uid/gid, even inside different containers. This can seem pretty confusing at first, so let’s illustrate it with a few examples:

https://www.elephdev.com/cDocker/294.html?lang=en&ref=addtabs

What does it mean

Now that we have discussed this, it makes sense that all methods of running a container with limited permissions use the host's user system:

1. If the process in the container is executing a known uid, then it may be as simple as restricting access to the host system so that the uid from the container has limited access.

2. A better solution is to use --user to start the container with a known uid (you can also use the username, but remember, this is just a more friendly way to provide the uid from the host's username system), Then restrict access to the uid on the host you decide to run the container on.

3. Because of how the uid and user name (and gid and group name) are mapped from the container to the host, specifying the user under which the containerized process runs can make the process appear to be owned by different users inside and outside the container.

https://cloud.tencent.com/developer/ask/sof/116089540

cannot change

docker build -t my-jenkins --build-arg uid=1003 --build-arg gid=1003 .