Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux