siginfo中的数据可信吗？

Question

我发现在 Linux 上，通过自己调用 rt_sigqueue 系统调用，我可以将任何我喜欢的内容放入 si_uid 和 si_pid 中字段并且调用成功并愉快地传递了错误的值。当然，对发送信号的 uid 限制提供了一些针对此类欺骗的保护，但我担心依赖此信息可能会很危险。有关于我可以阅读的主题的任何好的文档吗？为什么 Linux 允许让调用者指定 siginfo 参数而不是在内核空间中生成这些明显不正确的行为？这似乎很荒谬，特别是因为额外的系统 为了获取用户空间中的 uid/gid ，可能需要调用（以及因此的性能成本）。

编辑：基于我对POSIX（重点是我添加的）：

如果 si_code 为 SI_USER 或 SI_QUEUE、[XSI] 或任何小于或等于 0 的值，则信号由进程生成，并且 si_pid 和 si_uid 应设置为进程 ID 和真实用户 ID分别是发送者的。

我认为 Linux 的这种行为是不符合规范的，并且是一个严重的错误。

Answer 1

您引用的 POSIX 页面的该部分还列出了 si-code 的含义，其含义如下：

SI_QUEUE
    The signal was sent by the sigqueue() function.

该部分接着说：

如果信号不是由一个
列出的功能或事件
上面，si_code 应设置为
到信号特定值之一
XBD 中描述，或
实现定义的值是
不等于任何定义的值
如上所述。

如果只有 sigqueue() 函数使用 SI_QUEUE，则不会违反任何规定。您的场景涉及使用 SI_QUEUE 的 sigqueue() 函数之外的代码。问题是 POSIX 是否设想操作系统仅强制执行指定的库函数（而不是某些函数）不是 POSIX 定义的库函数）被允许进行具有某些特征的系统调用。我相信答案是“不”。

截至 2011 年 3 月 26 日 14:00 PST 的编辑：

此编辑是为了回应 R.. 八小时前的评论，因为该页面不会“让我留下足够长的评论：

我认为你基本上是对的。但系统要么兼容 POSIX，要么不兼容。如果非库函数执行的系统调用导致 uid、pid 和“si_code”的组合不合规，那么我引用的第二条语句清楚表明调用本身不合规。人们可以用两种方式解释这一点。一种方法是：“如果用户违反了这条规则，那么他就会使系统不合规。”但你是对的，我认为这很愚蠢。当任何非特权用户都可以使其不合规时，系统还有什么用呢？在我看来，修复方法是让系统知道不是库“sigqueue()”进行系统调用，然后内核本身应该将“si_code”设置为“SI_QUEUE”以外的其他值，并保留uid 和 pid 如您设置的那样。在我看来，你应该向内核人员提出这个问题。然而，他们可能会遇到困难；我不知道他们有什么安全的方法来检测系统调用是否由特定的库函数进行，看看库的功能如何。几乎根据定义，它们只是系统调用的方便包装。这可能就是他们所采取的立场，我知道这会令人失望。

（大量）编辑截至 2011 年 3 月 26 日 18:00 PST：

再次由于评论长度的限制。

这是对 R.. 大约一个小时前的评论的回应。

我对系统调用主题有点陌生，所以请耐心等待。

“内核 sysqueue 系统调用”是指“__NR_rt_sigqueueinfo”调用吗？这是我在这样做时发现的唯一一个：

grep -Ri 'NR.*queue' /usr/include

如果是这样的话，我想我不理解你原来的观点。内核将允许（非 root）我使用带有伪造的 pid 和 uid 的 SI-QUEUE 而不会出现错误。如果我将发送端编码为：

#include <sys/syscall.h>
#include <sys/types.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int    argc,
         char **argv
        )
{
  long john_silver;

  siginfo_t my_siginfo;

  if(argc!=2)
  {
    fprintf(stderr,"missing pid argument\n");

    exit(1);
  }

  john_silver=strtol(argv[1],NULL,0);

  if(kill(john_silver,SIGUSR1))
  {
    fprintf(stderr,"kill() fail\n");

    exit(1);
  }

  sleep(1);

  my_siginfo.si_signo=SIGUSR1;
  my_siginfo.si_code=SI_QUEUE;
  my_siginfo.si_pid=getpid();
  my_siginfo.si_uid=getuid();
  my_siginfo.si_value.sival_int=41;

  if(syscall(__NR_rt_sigqueueinfo,john_silver,SIGUSR1,&my_siginfo))
  {
    perror("syscall()");

    exit(1);
  }

  sleep(1);

  my_siginfo.si_signo=SIGUSR2;
  my_siginfo.si_code=SI_QUEUE;
  my_siginfo.si_pid=getpid()+1;
  my_siginfo.si_uid=getuid()+1;
  my_siginfo.si_value.sival_int=42;

  if(syscall(__NR_rt_sigqueueinfo,john_silver,SIGUSR2,&my_siginfo))
  {
    perror("syscall()");

    exit(1);
  }

  return 0;

} /* main() */

接收端编码为：

#include <sys/types.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int signaled_flag=0;

siginfo_t received_information;

void
my_handler(int        signal_number,
           siginfo_t *signal_information,
           void      *we_ignore_this
          )
{
  memmove(&received_information,
          signal_information,
          sizeof(received_information)
         );

  signaled_flag=1;

} /* my_handler() */

/*--------------------------------------------------------------------------*/

int
main(void)
{
  pid_t            myself;

  struct sigaction the_action;

  myself=getpid();

  printf("signal receiver is process %d\n",myself);

  the_action.sa_sigaction=my_handler;
  sigemptyset(&the_action.sa_mask);
  the_action.sa_flags=SA_SIGINFO;

  if(sigaction(SIGUSR1,&the_action,NULL))
  {
    fprintf(stderr,"sigaction(SIGUSR1) fail\n");

    exit(1);
  }

  if(sigaction(SIGUSR2,&the_action,NULL))
  {
    fprintf(stderr,"sigaction(SIGUSR2) fail\n");

    exit(1);
  }

  for(;;)
  {
    while(!signaled_flag)
    {
      sleep(1);
    }

    printf("si_signo: %d\n",received_information.si_signo);
    printf("si_pid  : %d\n",received_information.si_pid  );
    printf("si_uid  : %d\n",received_information.si_uid  );

    if(received_information.si_signo==SIGUSR2)
    {
      break;
    }

    signaled_flag=0;
  }

  return 0;

} /* main() */

然后我可以运行（非根）接收端：

wally:~/tmp/20110326$ receive
signal receiver is process 9023
si_signo: 10
si_pid  : 9055
si_uid  : 4000
si_signo: 10
si_pid  : 9055
si_uid  : 4000
si_signo: 12
si_pid  : 9056
si_uid  : 4001
wally:~/tmp/20110326$ 

在发送端看到这个（非根）：

wally:~/tmp/20110326$ send 9023
wally:~/tmp/20110326$ 

如您所见，第三个事件已欺骗 pid 和 uid。这不是你最初反对的吗？看不到 EINVAL 或 EPERM。我想我很困惑。

Answer 2

我同意 si_uid 和 si_pid 应该值得信赖，如果它们不值得信赖，那就是一个错误。但是，只有当信号是由子进程的状态更改生成的 SIGCHLD 时，或者 si_code 是 SI_USER 或 时，才需要这样做>SI_QUEUE，或者如果系统支持 XSI 选项和 si_code <= 0。 Linux/glibc 在其他情况下也会传递 si_uid 和 si_pid 值；这些通常不值得信赖，但这不是 POSIX 一致性问题。

当然，对于kill()，信号可能不会排队，在这种情况下，siginfo_t不提供任何附加信息。

rt_sigqueueinfo 不仅仅允许 SI_QUEUE 的原因可能是允许以最少的内核支持实现 POSIX 异步 I/O、消息队列和每进程计时器。在用户态实现这些需要能够分别使用 SI_ASYNCIO、SI_MESGQ 和 SI_TIMER 发送信号。我不知道glibc如何分配资源来预先对信号进行排队；在我看来，它似乎没有，只是希望 rt_sigqueueinfo 不会失败。 POSIX 明确禁止丢弃计时器到期（异步 I/O 完成、消息到达消息队列）通知，因为到期时有太多信号排队；如果资源不足，实施应拒绝创建或注册。这些对象都经过仔细定义，以便每个 I/O 请求、消息队列或计时器一次最多可以有一个正在运行的信号。