看起来你遇到的是Docker容器里非root用户调用setuid的pppd时，无法访问socat创建的PTY设备的权限问题，我来帮你一步步分析和解决。

首先得揪出核心问题：socat创建的/tmp/ppp0//tmp/tty0符号链接本身权限没问题，但它们指向的真实设备/dev/pts/1//dev/pts/2的权限配置才是关键。你可以先执行这条命令确认真实设备的权限：

ls -l /dev/pts/1 /dev/pts/2

大概率会看到类似这样的输出：

crw--w---- 1 usera tty 136, 1 Mar  8 15:33 /dev/pts/1
crw--w---- 1 usera tty 136, 2 Mar  8 15:33 /dev/pts/2

这里的权限crw--w----意味着只有创建者usera有读写权限，tty组仅拥有写权限，其他用户（包括pppd可能切换到的身份）完全无法访问。而pppd即使是setuid到root，它的默认行为也会在初始化后主动放弃root权限，切换回调用它的原用户usera——这时候就碰了权限壁。

解决方案1：测试环境快速方案——开放PTY全局权限 #

如果是测试环境优先便利性，可以直接在socat命令里添加mode=666参数，让创建的PTY对所有用户开放读写权限：

socat pty,link=/tmp/ppp0,echo=0,raw,b115200,mode=666 pty,link=/tmp/tty0,echo=0,raw,b115200,mode=666

执行后再看/dev/pts/X的权限会变成crw-rw-rw-，不管pppd以什么身份运行都能正常访问。

解决方案2：更安全的权限控制——让用户加入tty组 #

如果不想完全开放权限，可以分两步配置：

1. 在Dockerfile里把usera加入tty组，确保它拥有tty组的权限：

RUN usermod -aG tty usera

2. 修改socat命令，指定PTY的组为tty并开放组读写权限：

socat pty,link=/tmp/ppp0,echo=0,raw,b115200,mode=660,group=tty pty,link=/tmp/tty0,echo=0,raw,b115200,mode=660,group=tty

此时/dev/pts/X的权限会变成crw-rw----，tty组成员（包括usera）都能读写，pppd切换回usera后也能正常访问设备。

解决方案3：调整pppd运行参数——避免权限降级 #

如果你的pppd确实是setuid到root的，可以在启动命令里添加参数，阻止它主动放弃root权限：

pppd /tmp/ppp0 115200 noipdefault nodetach debug

其中debug参数能帮你输出更详细的日志，确认pppd访问设备时的真实用户身份，方便排查问题。

额外的Docker容器配置检查 #

如果以上方案都没效果，可能是Docker的安全限制在搞鬼：

• 启动容器时可以尝试添加--cap-add=SYS_ADMIN（比--privileged更温和），放开PTY相关的系统权限：

docker run -it --cap-add=SYS_ADMIN your-ubuntu-image

• 检查/dev/pts的挂载配置，执行mount | grep /dev/pts，正常应该看到类似：

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

如果gid不是tty组的默认ID（通常是5），可以在启动容器时手动指定挂载参数调整：

docker run -it --mount type=devpts,dst=/dev/pts,gid=5,mode=620 your-ubuntu-image

备注：内容来源于stack exchange，提问作者Rob