Docker容器中丢弃FSETID能力的影响及相关问题咨询

问题1：默认情况下，FSETID能力在Docker容器中允许执行哪些操作？ #

FSETID是Linux内核的权限能力，默认在Docker容器（以root用户运行时）开启，核心作用包括：

• 进程拥有该能力时，修改文件权限可保留SUID/SGID位，即便进程的有效UID/GID不是文件所有者。
• 针对目录，拥有该能力的进程创建文件时，新文件会继承目录的SGID位，不受进程自身GID影响。

问题2：丢弃FSETID能力后，容器内哪些具体操作会受到限制或影响？ #

丢弃FSETID后，即使是root进程也会失去以下能力：

• 修改文件权限时，无法保留或设置文件的SUID/SGID位，除非进程是文件的实际所有者。
• 创建新文件时，无法让新文件继承目录的SGID位，除非进程的有效GID与目录的GID完全一致。

问题3：为什么以非root用户运行并丢弃FSETID能力，仍能修改文件/文件夹权限、运行passwd命令？ #

原因分两部分：

1. 修改文件权限：非root用户修改自身拥有的文件/文件夹权限是Linux基础权限逻辑，和FSETID无关。FSETID仅管控「非所有者修改权限时能否保留SUID/SGID」，所有者修改权限本身不受该能力限制。
2. 运行passwd命令：passwd是SUID程序（所有者为root且带SUID位），执行时会以root权限运行。Docker容器默认保留了SETUID等必要能力，所以passwd可正常工作——FSETID不影响SUID程序的执行，仅影响设置SUID/SGID位的操作。

另外你的Dockerfile中myuser属于sudo组，执行sudo后会获取root权限，此时修改系统文件权限也和FSETID无关，因为root在容器中除被丢弃的能力外，其余权限基本不受限。

问题4：丢弃FSETID能力后与保留该能力存在差异的场景 #

可以通过以下场景直观验证差异：

场景步骤 #

1. 保留FSETID的容器测试
   运行容器：

   docker run -it --rm ubuntu:latest bash
   

   容器内执行：

   # 创建带SGID位的目录
   mkdir test_dir && chmod g+s test_dir
   # 创建非root用户并切换
   useradd -m testuser && su testuser
   # 在目录下创建文件
   touch test_dir/test_file
   # 查看文件权限
   ls -l test_dir/test_file
   

   输出会显示文件带有g+s（SGID位），因为root拥有FSETID能力，目录的SGID位被新文件继承。

2. 丢弃FSETID的容器测试
   运行容器：

   docker run -it --rm --cap-drop FSETID ubuntu:latest bash
   

   重复上述操作：

   mkdir test_dir && chmod g+s test_dir
   useradd -m testuser && su testuser
   touch test_dir/test_file
   ls -l test_dir/test_file
   

   此时查看文件权限会发现无SGID位——因为容器丢弃了FSETID，root创建的目录SGID位无法被非root用户创建的文件继承，符合FSETID的限制逻辑。

内容的提问来源于stack exchange，提问作者arsalan yavari