On Wed, Dec 07, 2011 at 02:01:21PM +0900, Tetsuo Handa wrote: > 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? Sure, you are always free to add if (pos == ERR_PTR(-EINVAL)) { pos = dentry_path(path->dentry, ...) /* do whatever you want to buffer to indicate that * beginning had been lost */ } since that's the _only_ reliable part of pathname information there is in such situation. What should be done to buffer contents is *really* up to you - what you have there is the path from the root of filesystem path points to and to path->dentry. Beginning *is* lost; the thing had been unmounted and this is all you have. Or you might want to do __d_path() from (path->mnt,path->mnt->mnt_root) to path - that's the path from the last mountpoint to your object; i.e. it may be shorter if that vfsmount had been a binding into the guts of filesystem, but that is what __d_path() as you used it would stabilize to once the race window is over. Again, that's what happens if you are hit with umount and there is *no* absolute path anymore. What should be done in such situation is really up to you - as far as I'm concerned, those races are among the reasons why pathname-based MAC is a fundamentally wrong idea. -- 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
