Re: [git pull] apparmor fix for __d_path() misuse

[Tetsuo Handa]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/