Jeff Layton <jlayton@xxxxxxxxxx> writes: > Thanks, that makes sense. The raciness was evident once you pointed it > out, so I think you're correct that we can't take this approach. > > Adding the missing revalidations is fine, but I don't believe that > helps to fix Pavel's issue. I'll go back and take a more careful look > at the suggestion that Miklos made and see whether it makes sense to > implement a new FS_* flag for this, and see what it'll take to fix > Pavel's issue. Fundamentally today the proc/fd links are special kind of hard link, the same kind as bind mounts and have the same issues crop up. Given that definition there is absolutely nothing wrong their behavior. The fact that we create the proc/fd implicitly is a little bit surprising and the source of the concerns. So far the cost of changing the semantics and breaking potentially valid user space applications appears to outweigh the potential security benefit. I can't find a reason for the missing revalidate. It is easy to get into a state where the destination of of a proc/fd/N symlink or a file bind mount has been deleted, and everything continues to work. You can even open d_dropped file descriptors. If you want confirmation just do: $ mkdir toy $ cd toy $ echo 123 > f $ touch g $ sudo mount --bind ./f ./g $ sleep 3000 < g & $ child=$! $ ls -l /proc/$child/fd/0 lr-x------ 1 eric eric 64 2009-11-19 13:27 /proc/28797/fd/0 -> /tmp/toy/g $ rm f $ ls -l /proc/$child/fd/0 lr-x------ 1 eric eric 64 2009-11-19 13:27 /proc/28797/fd/0 -> /tmp/toy/g (deleted) $ cat /proc/$child/fd/0 123 $ kill $child $ sudo umount ./g $ cat g $ rm g What we can't do right now is revalidate the source of a mount as that will make it impossible to find the vfsmount to unmount it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
