android - ParcelFileDescritor.createPipe()，又名 pipe(2) 和安全性

Question

请注意，虽然我是在 Android 环境下问这个问题，但它更像是一个关于 pipe(2) 的一般 unix 问题 ...

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

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

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

Answer 1

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

Linux 内核中的文件是 inode ( struct inode ) 和一些状态(例如搜索位置)的句柄。

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

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

创建 pipe结果产生两个文件描述符:读端和写端。它们有些神奇:从第一个文件描述符读取将返回写入第二个文件描述符的数据。在创建时，管道的两端只能被本进程访问。

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

通常在 C 中，您会使用 fopen获得一个 FILE * 结构，你可以 fread/fwrite/ETC。上。 C 运行时库通过打开一个文件描述符并将其包装为一个结构(包含额外的缓冲等)来实现这一点。 fdopen接受一个已经在本地进程中打开的文件描述符，以及围绕它的 FILE * 结构。

将各个部分放在一起:

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

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