lsof 看不到非标准路径下的句柄，是因为其依赖内核提供的文件系统信息和 /proc/PID/fd/ 符号链接解析，无法穿透 chroot、user namespace 或 bind-mount 等隔离机制还原真实路径。
lsof 为什么看不到非标准路径下的句柄？
默认情况下 lsof 不会过滤路径，但它依赖内核提供的文件系统信息和进程的 /proc/PID/fd/ 符号链接解析。如果进程通过 chroot、命名空间（如 unshare --user --pid）、或自定义挂载（如 mount --bind）隐藏了根目录或重映射了路径，lsof 显示的路径可能仍是“原始”路径，或者干脆显示为 unknown、DEL、inotify 等占位符——这不是 lsof 的 bug，而是它无法穿透隔离机制还原用户视角下的真实路径。
用 -P -n -F 配合 /proc 手动验证可疑 PID
当发现某个进程的 lsof -p PID 输出大量 DEL 或路径明显不匹配（比如显示 /tmp/.X11-unix 但该目录实际不存在），优先检查其 /proc/PID/fd/ 目录本身：
- 运行
ls -la /proc/PID/fd/—— 若能看到符号链接指向/dev/null、socket:[...]或anon_inode:[eventpoll]，说明句柄存在，但路径不可见 - 对每个 fd 运行
readlink /proc/PID/fd/N；若返回No such file or directory，大概率该 fd 指向已删除文件（DEL）或位于 chroot 环境中 - 用
lsof -P -n -F pfn -p PID输出机器可读格式，再用awk提取 fd 编号和类型，避免解析人类可读输出时被空格/换行干扰
排查 rootless 容器或 user namespace 进程
这类进程常驻于非特权用户空间，lsof 默认以当前用户权限运行，无法访问其他用户的 /proc 子树（即使 PID 可见）。常见现象是：ps aux | grep suspicious 能看到进程，但 lsof -p PID 报 can't identify protocol 或直接无输出。
- 必须用
sudo lsof -p PID，否则连 fd 列表都拿不到 - 若仍显示路径异常，检查该进程是否在 user namespace 中：执行
cat /proc/PID/status | grep Uid和cat /proc/PID/status | grep NSpid；若NSpid行有多个数字，说明它处于嵌套 PID namespace - 此时真实根路径需结合
nsenter -t PID -r /bin/sh -c 'pwd; ls -la /proc/self/fd'进入其 mount namespace 查看
识别真正可疑的句柄模式
不是所有异常路径都代表恶意行为。以下组合更值得警惕：
-
lsof -u $USER | grep -E "(DEL|socket|anon_inode)" | awk '{print $2}' | sort -u—— 提取频繁出现DEL且长期存活的 PID - 某进程打开大量
pipe或eventpoll但无对应网络监听（lsof -i -p PID为空），可能是隐蔽 C2 信道 -
lsof +D /nonstandard/path失败，但find /proc/*/fd -ls 2>/dev/null | grep nonstandard却能匹配到软链目标 —— 说明该路径被 bind-mount 过，原路径已被覆盖
真正的难点不在命令怎么敲，而在于判断「路径不可见」到底是权限不足、namespace 隔离，还是进程主动 unlink 后保持 fd 打开——这需要交叉比对 /proc/PID/{status,cmdline,maps} 才能下结论。
