应创建docker组并添加用户到该组，执行newgrp docker立即生效，同时配置daemon.json指定"group": "docker"或通过systemd override.conf固化socket属组权限，确保/var/run/docker.sock权限为srw-rw---- 1 root docker。
在统信UOS系统中避免普通用户因权限不足无法执行docker命令，或因过度授权导致容器逃逸、宿主机文件被篡改等安全风险，必须精准控制Docker守护进程访问权限、用户组隔离策略与socket文件访问控制。
确认Docker守护进程运行状态与socket路径
先检查Docker服务是否已启动且处于活跃状态：sudo systemctl status docker | grep "active (running)"。若无输出，说明服务未运行，后续所有权限配置均无效。
验证Docker Unix socket是否存在且权限受限：ls -l /var/run/docker.sock。正常应显示srw-rw---- 1 root docker，其中【group权限为rw-且属组为docker是关键前提】；若显示srw-rw-rw-或属组为root，则存在越权访问隐患，不可继续下一步。
创建专用docker组并添加用户
执行sudo groupadd docker创建组（若已存在则无报错，可忽略）。
将当前登录用户加入docker组：sudo usermod -aG docker $USER。注意【-aG参数不可省略，仅用-G会清空用户原有所有附加组】。
立即生效组权限，无需注销重登：newgrp docker。这一步跳过会导致后续docker命令仍提示“permission denied”，因为shell会话未加载新组信息。
禁用root用户直连docker.sock（高危操作）
方法一：修改Docker守护进程启动参数，强制限定socket属组
编辑/etc/docker/daemon.json，添加以下内容（若文件不存在请新建）：
{"group": "docker"}
方法二：手动修复socket文件属组与权限（临时补救）
执行sudo chown root:docker /var/run/docker.sock && sudo chmod 660 /var/run/docker.sock。该操作仅在当前会话有效，重启Docker服务后可能被覆盖。
方法三：通过systemd服务配置固化权限
创建覆盖配置目录：sudo mkdir -p /etc/systemd/system/docker.service.d
新建限制文件：sudo tee /etc/systemd/system/docker.service.d/override.conf [Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --group=docker
EOF
重载并重启服务：sudo systemctl daemon-reload && sudo systemctl restart docker。此时ls -l /var/run/docker.sock应稳定保持root:docker 660权限。
验证非root用户容器操作能力
切换至当前用户（无需sudo），运行docker info | grep "Name:"。若成功输出主机名，说明组权限已生效。
拉取轻量镜像测试最小权限边界：docker pull alpine:latest。成功即表示网络、镜像拉取、本地存储写入三项基础能力均在docker组权限下可控运行。
尝试挂载宿主机根目录（安全红线测试）：docker run --rm -v /:/host alpine:latest ls /host/etc。若命令被拒绝或容器立即退出，说明默认安全策略（如userns-remap未启用时的默认隔离）仍在起效；若能列出宿主机/etc内容，则表明权限配置存在严重宽松漏洞，需立即回查daemon.json与socket权限。
