On Mon, Mar 02, 2020 at 02:27:08PM +0000, David Howells wrote: > Christian Brauner <christian.brauner@xxxxxxxxxx> wrote: > > > > AT_SYMLINK_NOFOLLOW only applies to the last pathname component anyway, > > > so it's relatively little protection. > > > > So this is partially why I think it's at least worth considerings: the > > new RESOLVE_NO_SYMLINKS flag does block all symlink resolution, not just > > for the last component in contrast to AT_SYMLINK_NOFOLLOW. This is > > 278121417a72d87fb29dd8c48801f80821e8f75a > > That sounds like a potentially significant UAPI change. What will that break? I think we settled this and can agree on RESOLVE_NO_SYMLINKS being the right thing to do, i.e. not resolving symlinks will stay opt-in. Or is your worry even with the current semantics of openat2()? I don't see the issue since O_NOFOLLOW still works with openat2(). Christian
