伪终端（ unlockpt / TIOCSPTLCK ）是安全功能吗？

Question

打开伪终端的主部分后

int fd_pseudo_term_master = open("/dev/ptmx",O_RDWR);

有/dev/pts/[NUMBER]创建的文件，代表slave他伪终端的部分。

像我这样无知的人可能会想象，做完ptsname(fd_pseudo_term_master,filename_pseudo_term_slave,buflen);一个人就应该简单地 做int fd_pseudo_term_slave = open(filename_pseudo_term_slave,O_RDWR);和做好。

但是，必须有一个非常重要的“锁定”伪终端从属用例，因为为了使事情简单，在进行open调用之前，必须使用man 3 unlockpt来“解锁”。

我无法找出这个用例是什么？伪终端初始锁定需要什么？代码实现了什么（取自 libc）

/* Unlock the slave pseudo terminal associated with the master pseudo
   terminal specified by FD.  */
int
unlockpt (int fd)
{
#ifdef TIOCSPTLCK
  int save_errno = errno;
  int unlock = 0;

  if (ioctl (fd, TIOCSPTLCK, &unlock))
    {
      if (errno == EINVAL)
        {
          errno = save_errno;
          return 0;
        }
      else
        return -1;
    }
#endif
  /* If we have no TIOCSPTLCK ioctl, all slave pseudo terminals are
     unlocked by default.  */
  return 0;
}

如果可能，答案将详细说明历史或当前的用例。

问题的奖励部分是：

当前的 linux 内核是否仍然依赖于“锁定伪终端从属设备”的这种功能？

想法：这是避免赛车条件的低效尝试吗？

等待答案我已经更多地研究了 linux 内核源代码，但我自己却没有任何好的答案。然而，似乎可以从伪终端的初始锁定情况“提取”的一种用途是为伪终端主进程提供一些时间来设置对文件的某些访问权限/dev/pts/[NUMBER]，以防止某些用户首先访问文件。这可以成为答案的一部分吗？奇怪的是，然而，这种“初始锁定”状态似乎并不能真正阻止从文件的多次打开，至少我认为在这里保证原子性。

Answer 1

旧的AT＆T系统5机制伪终端从设备是它们是普通的持久性下字符的设备节点/dev。有一个多路复用器主设备/dev/ptmx。为伪终端设备旧4.3BSD机构具有平行对普通的持久性下主从设备节点/dev。

在这两种情况下，这意味着从属设备文件在最后一次文件描述符关闭后保留其最后的所有权和权限。因此，grantpt()在（重新）分配（重新）分配（重新使用）伪终端之后，修复从属设备文件的所有权和权限的功能的演变。

这反过来意味着有一个窗口，当程序在open()和grantpt()之前拥有从设备的人之间设置一个重复使用的伪终端时，可以潜入并打开它，并有可能访问其他人的终端. 因此，伪终端从属字符设备以锁定状态开始，在该状态下它们无法打开并在成功执行unlockpt()后解锁grantpt()。

多年来，事实证明这是不必要的。

现在，从设备文件不是持久化的，因为内核自己制造和销毁东西/dev。打开主设备的行为要么重置从设备的权限和所有权，要么直接重新创建从设备文件（在后一种情况下，当所有打开的文件描述符都关闭时，从设备文件再次消失），在任何一种情况下相同的系统调用。

• 在 OpenBSD 上，这是设备PTMGET上 I/O 控制功能的一部分/dev/ptm。 /dev仍然是磁盘卷，内核在内部发出相关调用以在那里创建新设备节点并重置其所有权和权限。
• 在 FreeBSD 上，这是由posix_openpt()系统调用完成的。 /dev根本不是光盘卷。它是一个devfs文件系统。它不包含“多路复用器”设备或主设备文件，因为它posix_openpt()是一个彻底的系统调用，而不是包装ioctl()在打开的文件描述符上。从设备出现在devfs其pts/目录下的文件系统中。

因此，内核确保他们从一开始就拥有正确的权限和所有权，并且没有机会之窗让他们拥有陈旧的权限。因此grantpt()和unlockpt()库函数本质上是无操作的，其唯一剩余的功能是检查它们传递的文件描述符并设置EINVAL它是否不是伪终端的主端，因为程序可能正在做一些愚蠢的事情，例如传递非伪-终端文件描述符到这些函数并期望它们返回错误。

有一段时间在 Linux 上，伪终端从设备是持久设备节点。GNU C 库grantpt()不是系统调用。相反，它分叉并执行了一个名为 的 set-UID 帮助程序pt_chown，这让没有 set-UID 可执行文件的人群感到非常沮丧。（grantpt()必须允许非特权用户更改其不一定拥有的特殊设备文件的所有权和权限，请记住。）所以仍然有机会之窗，Linux 仍然必须维护unlockpt().

然而，它的“新”devpts文件系统（其中“新”的意思是几年前引入的，现在）几乎允许与在 FreeBSD 上相同的做事方式devfs。有一些差异。

• 还有一个“多路复用器”设备。
  • 在较旧的“新”devpts系统中，这是ptmx不同devtmpfs文件系统中的设备，文件devpts系统仅包含自动创建/销毁的从设备文件。传统上，设置是/dev/ptmx和一个随附的devpts安装在/dev/pts.
  • 但Linux的人想拥有多个完全独立的实例devpts文件系统，用于容器等，这被证明是相当困难的时候出现了同步的（正确的）两个文件系统很多 devtmpfs和devpts文件系统。因此，在较新的“新”devpts系统中，所有设备、多路复用器和从设备都在一个文件系统中。为了向后兼容，默认设置是新ptmx节点不可访问，除非设置新的ptmxmode挂载选项。
  • 在更新的仍然是“新”devpts的ptmx文件devpts系统中的设备文件现在是主要的多路复用器，其中ptmx的devtmpfs要么是内核提供的垫片，它试图模仿符号链接、绑定安装，要么是一个普通的旧实际符号链接到pts/ptmx.
• 内核并不总是按照grantpt()应有的方式设置所有权和权限。设置错误的挂载选项（GID 或0620gid以外的其他选项）会触发 GNU C 库中的回退行为。为了在 GNU C 库中根据需要减少到无操作，内核必须不分配打开进程的组（即必须有明确的设置），分配的组必须是组，而新的组创建的从设备必须正好是 0620。ttymodegrantpt()gidttymode

/dev/pts/ptmx默认情况下不开启和 GNU C 库没有完全减少grantpt()到无操作都是因为内核和 C 库没有保持同步。每个都必须使用另一个的旧版本。Linux 仍然必须提供一个较旧的/dev/ptmx. pt_chown如果没有devpts带有正确挂载选项的新文件系统，GNU C 库仍然必须退回到运行状态。

因此unlockpt()，如果devpts挂载选项错误并且 GNU C 库因此不得不退回到在grantpt().

进一步阅读

• https://unix.stackexchange.com/a/470853/5132
• 解决这个 glibc 问题的最佳方法是什么？
• https://unix.stackexchange.com/a/214685/5132
• Documentation/filesystems/devpts.txt. Linux内核。
• 丹尼尔·伯兰奇 (2009-05-20)。/dev/pts必须使用 'newinstance' 挂载标志来避免容器的安全问题。红帽错误 #501718。
• 乔纳森·德·博因·波拉德 (2018)。open-controlling-tty. 小吃指南。软件。
• 乔纳森·德·博因·波拉德 (2018)。vc-get-tty. 小吃指南。软件。
• 乔纳森·德·博因·波拉德 (2018)。pty-get-tty. 小吃指南。软件。