非root用户运行stunnel报错setgroups: Operation not permitted的技术问询
核心问题分析
报错setgroups: Operation not permitted的根源是：你在stunnel配置里指定了setuid=65532和setgid=65532，但容器已经以UID 65532的非root用户启动。此时stunnel尝试执行setgroups系统调用切换用户组，而该操作需要CAP_SETGID权限，非root用户默认没有这个权限，直接导致启动失败。
直接解决报错的两种方案
方案1：移除stunnel配置中的setuid/setgid配置
容器已经通过USER ${APP_USER}:${APP_USER}指定了运行用户，stunnel启动时会直接继承该用户身份，完全不需要在stunnel配置里重复设置用户切换。修改你的stunnel配置，删除以下两行：
setuid = 65532 setgid = 65532
修改后stunnel会以容器指定的非root用户正常运行，不会触发setgroups调用，权限报错直接消失。
方案2：给stunnel二进制添加CAP_SETGID权限
如果必须保留stunnel配置中的setuid/setgid，可以在Dockerfile中给stunnel添加必要权限，让非root用户也能执行用户组切换：
在RUN apk update && apk add ...步骤之后添加：
RUN setcap cap_setgid+ep /usr/bin/stunnel
这条命令会给stunnel二进制文件添加CAP_SETGID权限，允许其在非root用户下执行用户组切换操作。
关于setuid脚本方案的优缺点
你当前用带setuid位的脚本启动stunnel确实能解决问题，但存在明显弊端：
- 安全风险：setuid脚本如果被篡改，攻击者可通过脚本以root权限执行任意命令，直接突破容器权限控制。
- 维护复杂度：额外的脚本增加了镜像的维护成本，排查问题时需要多一层排查环节。
更优的整体架构建议
结合你的需求（不修改oauth2-proxy代码，通过stunnel实现客户端证书认证），优先推荐方案1，理由如下：
- 最简单直接：不需要额外权限配置或脚本，减少不必要的攻击面。
- 符合最小权限原则：容器以非root用户运行，stunnel直接继承该身份，无需额外权限提升。
- 减少配置冗余：容器已经指定运行用户，stunnel配置无需重复设置用户切换。
额外注意事项
当前Dockerfile中已经执行chown ${APP_USER}:${APP_USER} /etc/stunnel，确保了非root用户能正常读取证书文件/etc/stunnel/stunnel.pem，这部分配置无需调整。
内容的提问来源于stack exchange，提问作者Jeremy
