adb pull命令执行时提示“permission denied”如何解决？

Question

在使用 `adb pull` 命令从安卓设备拉取系统文件或应用数据时，常遇到“Permission denied”错误。该问题通常源于目标文件的读取权限受限，如系统分区（/system、/data）或应用私有目录（/data/data/包名）仅允许 root 用户访问。即使设备已获取 root 权限，若 adb 未以 root 身份运行，仍会因权限不足导致操作失败。此外，SELinux 策略或设备处于用户模式（而非开发者/调试模式）也可能限制访问。解决方法包括：确保设备开启 USB 调试并授权电脑；尝试执行 `adb root` 提升 adb 权限；对 rooted 设备使用 `adb shell su -c "cat /path/to/file" > local_file` 绕过权限限制；或通过 `adb backup` 间接获取应用数据。理解权限机制并结合 root 工具可有效规避此问题。

Answer 1

1. 问题背景与常见场景

在 Android 开发和逆向分析过程中，adb pull 是一个常用的命令，用于从连接的设备中提取文件到本地主机。然而，当尝试访问系统关键目录（如 /system、/data）或应用私有数据路径（如 /data/data/com.example.app）时，开发者常遇到“Permission denied”错误。

该问题的根本原因在于 Linux 文件权限模型与 Android 安全机制的叠加作用。Android 基于 Linux 内核构建，采用多用户隔离机制，每个应用运行在独立的 UID 下，其数据默认仅对自身可读写。此外，系统分区通常挂载为只读或受限访问模式。

2. 权限层级解析：由浅入深的技术栈剖析

1. Linux 文件权限：Android 使用标准的 Unix 权限体系（rwx），目标文件若不具备全局读取权限（o+r），非所属用户无法访问。
2. ADB 用户上下文：默认情况下，adb shell 运行在有限权限用户（如 shell 或 app）下，无法直接读取 root-only 路径。
3. Root 权限获取状态：即使设备已刷入 Magisk 或 SuperSU，adb 并不会自动以 root 身份运行，需显式启用。
4. SELinux 策略限制：即使拥有 root 权限，SELinux 的强制访问控制（MAC）可能阻止特定域执行文件读取操作。
5. 构建类型影响：用户构建（user build）设备通常禁用 adb root，而用户调试版（userdebug）或工程版（eng）则允许。

3. 典型错误示例与诊断流程

$ adb pull /data/data/com.example.app/databases/app.db
Pulling: /data/data/com.example.app/databases/app.db
remote: /data/data/com.example.app/databases/app.db: Permission denied
error: failed to copy 'app.db' to '.': No such file or directory

诊断步骤如下：

步骤	命令	预期输出/判断依据
1. 检查设备连接与授权	adb devices	设备出现在列表且状态为 device
2. 验证是否支持 root 提权	adb root	返回 restarting adbd as root 表示成功
3. 查看当前 shell 用户	adb shell whoami	应为 root（提权后）
4. 检查 SELinux 状态	adb shell getenforce	Enforcing 可能导致拦截
5. 测试文件是否存在并查看权限	adb shell ls -l /data/data/com.example.app	确认所有者及读权限

4. 解决方案矩阵

• 方法一：提升 ADB 到 Root 上下文

  adb root
  adb remount
  adb pull /system/app/Music.apk ./Music.apk

  注意：adb root 仅在 userdebug/eng 构建上有效。
• 方法二：通过 su 执行命令绕过权限

  adb shell "su -c 'cat /data/data/com.example.app/shared_prefs/config.xml'" > config.xml

  此方式适用于已 root 设备，利用 root shell 执行读取动作并将结果重定向至本地。
• 方法三：使用 adb backup 获取应用数据

  adb backup -f backup.ab com.example.app

  后续可通过工具（如 abe）解包 backup.ab 获取内部数据。
• 方法四：临时关闭 SELinux（谨慎使用）

  adb shell su -c "setenforce 0"

  将 SELinux 设为 Permissive 模式，解除策略限制，但存在安全风险。

5. 高级技巧与自动化流程设计

对于频繁进行取证或调试的工程师，可编写脚本实现智能权限适配逻辑：

#!/bin/bash
PKG="com.example.app"
DEVICE_FILE="/data/data/$PKG/databases/data.db"
LOCAL_FILE="./data.db"

# Attempt root mode first
adb root &> /dev/null
if adb shell "[ -r $DEVICE_FILE ]" ; then
    adb pull $DEVICE_FILE $LOCAL_FILE
else
    echo "Direct pull failed, trying via su..."
    adb shell "su -c 'cat $DEVICE_FILE'" > $LOCAL_FILE
fi

6. 安全边界与合规考量

尽管技术手段多样，但在企业级开发或合规审计中必须注意：

• 不得在生产环境设备上随意开启 root 或关闭 SELinux；
• 应用数据属于用户隐私，提取行为需符合 GDPR、CCPA 等法规要求；
• 自动化脚本应在受控环境中运行，并记录操作日志。

7. 架构级应对策略流程图

graph TD
    A[开始提取文件] --> B{设备是否连接?}
    B -- 是 --> C{ADB 是否授权?}
    C -- 是 --> D{目标路径是否公开?}
    D -- 是 --> E[执行 adb pull]
    D -- 否 --> F{设备是否 rooted?}
    F -- 是 --> G[使用 su + cat 提取]
    F -- 否 --> H{是否为应用数据?}
    H -- 是 --> I[尝试 adb backup]
    H -- 否 --> J[检查 SELinux 状态]
    J --> K{SELinux 是否 Enforcing?}
    K -- 是 --> L[setenforce 0 临时关闭]
    K -- 否 --> M[重新尝试 pull]
    G --> N[保存至本地]
    I --> N
    M --> N
    N --> O[结束]