On Mon, May 18, 2015 at 8:10 PM, Calvin Owens <calvinow...@fb.com> wrote: > Currently, /proc/<pid>/map_files/ is restricted to CAP_SYS_ADMIN, and > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface is > very useful for enumerating the files mapped into a process when the > more verbose information in /proc/<pid>/maps is not needed. It also > allows access to file descriptors for files that have been deleted and > closed but are still mmapped into a process, which can be very useful > for introspection and debugging. > > This patch moves the folder out from behind CHECKPOINT_RESTORE, and
I'm fine with this. > removes the CAP_SYS_ADMIN restrictions. With that change alone, > following the links would have required PTRACE_MODE_READ like the > links in /proc/<pid>/fd/*. I'm still not at all convinced that this is safe. Here are a few ways that it could have unintended consequences: 1. Mmap a dma-buf and then open /proc/self/map_files/addr. You get an fd pointing at a different inode than you mapped. (kdbus would have the same problem if it were merged.) 2. Open a file with O_RDONLY, mmap it with PROT_READ, close the file, then open /proc/self/map_files/addr with O_RDWR. I don't see anything preventing that from succeeding. 3. Open a file, mmap it, close the fd, chroot, drop privileges, open /proc/self/map_files/addr, then call ftruncate. So NAK as-is, I think. Fixing #1 would involve changing the way mmap works, I think. Fixing #2 would require similar infrastructure to what we'd need to fix the existing /proc/pid/fd mode holes. I have no clue how to even approach fixing #3. What's the use case of this patch? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
