如何查看Lambda容器中遗留二进制文件尝试访问的文件

一、优化本地Lambda环境模拟，还原真实运行条件 #

• 模拟Lambda的普通用户权限：Lambda运行时使用非root用户（UID通常为1000左右，用户名为sbx_user1051），本地测试时需添加--user 1000:1000参数，避免root权限掩盖真实问题：

  docker run --read-only --rm --tmpfs /tmp --user 1000:1000 -p 9000:8080 test-image
  

• 还原Lambda文件系统权限结构：确保镜像中/var/task（代码目录）、/opt（层目录）的权限与Lambda一致——目录权限设为755，二进制文件权限设为755（执行权限），且文件所属用户/组为普通用户可访问的范围。
• 启用Runtime Interface Emulator调试模式：添加DEBUG=1环境变量，输出更详细的运行时权限交互日志：

  docker run --read-only --rm --tmpfs /tmp --user 1000:1000 -e DEBUG=1 -p 9000:8080 test-image
  

二、替代strace的文件访问追踪工具 #

• 打包静态编译版strace到镜像：Lambda环境无法直接安装strace，但可以在Amazon Linux 2环境中编译静态版strace（无依赖），再复制到你的镜像中：
  1. 临时启动Amazon Linux 2容器：docker run -it amazonlinux:2 bash
  2. 安装静态strace：yum install -y strace-static
  3. 将/usr/bin/strace复制到本地，再添加到你的Dockerfile中：COPY strace /usr/bin/strace
  4. 在Lambda中运行追踪命令：strace -f -e file /var/task/your-binary，会输出所有文件访问的系统调用及权限结果。
• 在Node.js wrapper中添加权限检查：调用二进制前，主动检查关键路径的权限，将结果输出到CloudWatch日志：

  const fs = require('fs').promises;
  
  async function checkPermissions() {
    const paths = [
      '/var/task/your-binary',
      '/tmp',
      // 二进制可能访问的其他路径
    ];
    for (const path of paths) {
      try {
        await fs.access(path, fs.constants.R_OK | fs.constants.X_OK);
        console.log(`[PERMISSION OK] ${path}`);
      } catch (err) {
        console.error(`[PERMISSION FAIL] ${path}: ${err.message}`);
      }
    }
  }
  

• 使用auditd追踪文件访问（本地模拟）：在本地镜像中安装auditd，配置规则追踪二进制的所有系统调用：

  # 在镜像中安装auditd
  yum install -y audit
  # 配置追踪规则
  auditctl -a exit,always -F path=/var/task/your-binary -S all
  # 运行二进制后查看日志
  cat /var/log/audit/audit.log | grep your-binary
  

三、额外排查方向 #

• 检查二进制动态依赖：用ldd your-binary查看依赖库，确认Lambda环境（Amazon Linux 2）中存在这些库，若缺失需将依赖库打包到镜像的/lib64或/opt/lib目录。
• 排查SELinux限制：Lambda环境启用了SELinux强制模式，本地可尝试开启SELinux并测试，看是否出现类似权限拦截。
• 分析CloudWatch详细日志：Lambda日志中可能包含Node.js调用二进制时的完整错误栈，重点关注是否有特定路径的权限拒绝信息。

内容的提问来源于stack exchange，提问作者Shawn MacIntyre