Al Viro wrote: > > How commonly can conditions that make d_absolute_path() return -EINVAL happen? > > Race with umount -l, basically. d_absolute_path() will return -EINVAL if lazy unmount happens. I see. Then, I prefer not denying the request with -EINVAL no matter how unreliable the returned pathname is. I don't want to deny the request unless -ENOMEM happens or rejected by the policy. > In that case the pathname is completely > unreliable - if I do umount -l /mnt, pathnames that would be under mnt > may get truncated on *ANY* mountpoint. Not "always cut on /mnt"; not "always > cut on the last mountpoint"; it's "everything from root to arbitrary mountpoint > on that path is not noticed". Unfortunate specification for pathname based access control. But since I assume that multiple LSM modules can run in parallel ( http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf), I leave more stricter decisions to inode based access control. So, can we keep behavior of tomoyo_get_absolute_path() unchanged? -- 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
