On 2020-03-02, Christian Brauner wrote: > On Mon, Mar 02, 2020 at 02:50:03PM +0000, David Howells wrote: > > Christian Brauner wrote: > > > > > 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(). > > > > Say, for example, my home dir is on a network volume somewhere and /home has a > > symlink pointing to it. RESOLVE_NO_SYMLINKS cannot be used to access a file > > inside my homedir if the pathwalk would go through /home/dhowells - this would > > affect fsinfo() - so RESOLVE_NO_SYMLINKS is not a substitute for > > AT_SYMLINK_NOFOLLOW (O_NOFOLLOW would not come into it). > > I think we didn't really have this issue/face that question because > openat() never supported AT_SYMLINK_{NO}FOLLOW. Whereas e.g. fsinfo() > does. So in such cases we are back to: either allow both AT_* and > RESOLVE_* flags (imho not the best option) or add (a) new RESOLVE_* > variant(s). It seems we leaned toward the latter so far... So, RESOLVE_NO_TRAILING_SYMLINKS? ... *sigh*. Yeah, okay I'm fine (though not super happy) with that. We'd also presumably need RESOLVE_NO_TRAILING_AUTOMOUNTS for David's AT_NO_AUTOMOUNT usecases -- as well as RESOLVE_NO_AUTOMOUNTS eventually. Now let's just hope no new syscalls need both AT_RECURSIVE and RESOLVE_NO_SYMLINKS -- that will put us in a very interesting situation where you have two ways of specifying "don't follow trailing symlinks"... -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH