如何使用bpf_get_current_task分析setpgid系统调用中的进程组ID设置过程

bpf_get_current_task是eBPF里一个非常实用的辅助函数，它返回当前CPU正在运行的进程对应的task_struct指针，让我们在内核态拿到进程的全部上下文信息。当我们想分析setpgid这个系统调用时，仅仅知道参数是不够的，还需要知道调用者的会话、进程组、父进程等信息，这时bpf_get_current_task就派上了用场。本文将从原理、代码实现和实际验证三个层面，完整讲解如何用它分析进程组ID的设置过程。

一、setpgid系统调用的内核行为与进程组概念

要分析setpgid，首先得明白它到底做了什么。在Linux中，进程组是一个或多个进程的集合，主要用于作业控制，比如终端按下Ctrl+C时，信号会发给整个前台进程组。每个进程都有一个进程组ID（pgid），通常等于组长的PID。setpgid的作用就是把某个进程加入到指定的进程组中，或者让它成为新组长。

内核在处理setpgid时会做一系列严格校验，任何一条不满足都会直接返回错误码，常见的有EPERM、ESRCH、EACCES等。理解这些校验逻辑，是我们编写eBPF观测程序的基础。主要校验规则包括：目标进程必须是调用者自己或者它的子进程；子进程不能已经执行过exec（否则返回EACCES）；进程组ID必须大于0；如果要加入一个已存在的组，该组必须存在于同一个会话中；如果要新建组，目标进程的PID必须等于要设置的pgid。

从内核实现角度看，setpgid最终会在sys_setpgid或其内部函数里，通过task_struct结构体读取pids数组中PIDTYPE_PGID对应的pid结构，然后调用change_pid完成进程组的切换。而bpf_get_current_task返回的正是task_struct指针，借助BPF CO-RE的偏移读取能力，我们可以直接观察这些字段在调用前后的变化。

二、编写eBPF程序捕获setpgid调用

环境准备方面，需要内核版本支持BTF（建议5.x以上），并安装clang、llvm以及libbpf开发库。以libbpf + BPF CO-RE的方式为例，我们编写一个kprobe程序挂载到sys_setpgid入口，同时用bpf_get_current_task获取当前任务上下文。

先定义事件结构和BPF程序骨架。代码中用bpf_get_current_task拿到task_struct指针后，再借助BPF核心读取宏bpf_core_read，安全地访问real_parent、tgid、pid等字段，从而在事件里同时记录调用者信息和目标进程参数。

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>

struct event {
    u32 caller_pid;      /* 调用者的tgid */
    u32 caller_ppid;     /* 调用者父进程 */
    u32 target_pid;      /* setpgid的第一个参数 */
    u32 target_pgid;     /* setpgid的第二个参数 */
    u32 caller_pgid;     /* 调用者当前进程组 */
};

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 4096);
} events SEC(".maps");

SEC("kprobe/sys_setpgid")
int BPF_KPROBE(trace_setpgid, pid_t pid, pid_t pgid)
{
    struct event e = {};
    struct task_struct *task;

    /* 关键点：获取当前正在执行的task_struct */
    task = (struct task_struct *)bpf_get_current_task();
    if (!task)
        return 0;

    e.caller_pid = bpf_get_current_pid_tgid() >> 32;
    e.target_pid = pid;
    e.target_pgid = pgid;

    /* 通过CO-RE读取父进程PID */
    BPF_CORE_READ_INTO(&e.caller_ppid, task, real_parent, tgid);

    /* 读取当前进程组ID，PIDTYPE_PGID对应pids数组下标2 */
    struct pid *pgrp;
    BPF_CORE_READ_INTO(&pgrp, task, thread_pid, numbers[0].pid);
    /* 更简洁的方式：借助辅助字段，这里演示思路 */

    bpf_ringbuf_output(&events, &e, sizeof(e), 0);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

这段代码的核心思路是：入口探针记录参数与调用上下文，出口探针记录返回值，两个事件在用户态通过PID和时间戳关联。如果想进一步验证内核是否真的修改了进程组，可以再加一个kretprobe，在sys_setpgid返回后重新读取task_struct中的进程组字段，对比调用前后的差异。

用户态加载程序部分使用libbpf的通用框架即可，重点是用ring_buffer__poll持续消费events映射。每次捕获到事件，打印调用者PID、目标PID和期望设置的pgid，再对照返回值判断是否校验通过。

三、触发场景验证与常见错误分析

程序运行后，用一个简单的测试脚本来触发各种返回码。写一段C测试代码，分别尝试：给自己设置新进程组（预期成功）、给已exec的子进程设置组（预期EACCES）、跨会话设置（预期EPERM）。

#include <stdio.h>
#include <unistd.h>
#include <errno.h>

int main(void)
{
    /* 场景1：让自己成为新组长，应返回0 */
    int ret = setpgid(0, 0);
    printf("setpgid(0,0) ret=%d errno=%d\n", ret, errno);

    /* 场景2：设置非法pgid为负值，应返回EINVAL */
    ret = setpgid(0, -1);
    printf("setpgid(0,-1) ret=%d errno=%d\n", ret, errno);

    /* 场景3：给不存在的进程设置，应返回ESRCH */
    ret = setpgid(99999, 99999);
    printf("setpgid(99999) ret=%d errno=%d\n", ret, errno);
    return 0;
}

结合eBPF输出可以看到一个有意思的现象：即使setpgid最终失败，kprobe入口事件依然会被记录，因为探针挂在函数入口，而校验发生在函数体内部。这正是入口与出口探针需要配合使用的原因。此外，在shell中执行管道命令时，bash会默认调用setpgid把整条管道放入同一进程组，通过我们的观测程序可以清晰看到每个子进程在exec前被设置pgid的时序，这对理解作业控制机制很有帮助。

还有一点值得注意：多线程程序中bpf_get_current_task返回的是当前线程对应的task_struct，其tgid字段才是用户态眼中的进程PID。如果分析目标是线程级别的行为，应当读取pid字段而不是tgid，否则数据会全部归并到主线程，造成误判。另外，如果目标内核开启了内核指针屏蔽，直接把task_struct指针传回用户态没有意义，必须在内核态完成字段读取，只传递解析后的数值。

总结来说，bpf_get_current_task配合CO-RE字段读取，让我们能够以极低开销观察到setpgid的完整决策链条：谁发起的调用、参数是什么、内核基于哪些校验规则给出结论。这套方法同样可以推广到setsid、getpgid等进程管理相关系统调用的分析中，是理解Linux进程组织结构的好切入点。

bpf_get_current_tasksetpgideBPF进程组ID修改时间：2026-09-05 11:20:34