ParcelFileDescritor.createPipe()、又名 pipe(2) 和安全性

Question

请注意，虽然我在 Android 的上下文中提出这个问题，但它更像是一个关于 pipe(2) 的一般性 unix 问题......

要将大量数据从一个进程传输到另一个进程，可以使用ParcelFileDescritor.createPipe()，然后通过 binder 将管道的读取端发送到另一个进程。 ParcelFileDescritor.createPipe() 直接映射到 unix pipe(2) 系统调用。

虽然 FD 通过 binder 安全地传输到另一个进程，但由于 FD 最终只是一个 int，它是否有可能被恶意进程发现，甚至猜测、打开和读取？

根据我的阅读，这似乎归结为通过默默无闻来实现安全。只要你不知道，也猜不到 FD int 值，就可以了。匿名管道不会公开以其他方式发现 FD 的方法。但从理论上讲，似乎有人可以编写一个具有大量线程的应用程序，这些线程不断尝试基于随机 int 值打开 int，可能会利用一些选择数字的模式并最终利用 pipe(2)。

Answer 1

Linux 内核为每个进程 (more or less) 跟踪一个文件描述符表 (struct fdtable)。此表中的条目由小整数索引——从 0、1、2 等开始，新条目被赋予最小的可用整数——并且每个条目都指向一个打开的文件 (struct file)。

Linux 内核中的文件是一个 inode (struct inode) 的句柄和一些状态（例如查找位置）。

如果多次打开同一个文件，文件描述符表中会有多个条目，每一个都指向不同的文件结构，每一个都指向同一个inode结构。

如果你打开一个文件，然后dup文件描述符，你将在文件描述符表中有多个条目，每个条目都指向同一个文件结构。

创建pipe 会产生两个文件描述符：读取端和写入端。它们有点神奇：从第一个文件描述符读取将返回写入第二个文件描述符的数据。在创建的时候，管道的两端只有这个进程可以访问。

将文件描述符传递给另一个进程（通常由 sendmsg 通过附加了辅助 SCM_RIGHTS 的 AF_UNIX 域套接字完成，但在 Android 上由带有 Parcel.writeFileDescriptor 的 Binder.transact 完成）导致一个新条目被添加到接收进程的文件描述符表中，指向与发送进程的文件描述符表中的原始条目相同的文件结构。 NB：两个进程中同一个文件的整数索引是不相关的；事实上，它可能会有所不同。

通常在 C 中，您将使用 fopen 来获得 FILE * 结构，您可以使用 fread/fwrite/等。在。 C 运行时库通过打开文件描述符并将其包装为结构（包含额外的缓冲等）来完成此操作。 fdopen 采用已在本地进程中打开的文件描述符，以及围绕它的 FILE * 结构。

拼凑：

没有其他进程可以通过猜测 FD 编号来打开文件，因为这些数字仅在单个进程中有意义。* 在进程之间传递文件描述符是安全的，由正在操作只有内核拥有的对象的内核进行调解访问。

*给定适当的权限，您可以通过/proc/$PID/fd/$FD 伪文件系统找到其他进程的文件描述符并自己重新打开它们。但是，“适当的权限”是“相同的用户或 root”。在 Android 上，所有应用程序都以不同的用户身份运行，没有一个以 root 身份运行——这是不可能的。此外，Android 的 SELinux 策略会阻止应用程序与 /proc 接口进行交互。