[Cc Florian since that ends up on libc's table sooner or later...] On Fri, Feb 28, 2020 at 02:53:32PM +0000, David Howells wrote: > > I've been told that RESOLVE_* flags, which can be found in linux/openat2.h, > should be used instead of the equivalent AT_* flags for new system calls. Is > this the case? Imho, it would make sense to use RESOLVE_* flags for new system calls and afair this was the original intention. The alternative is that RESOLVE_* flags are special to openat2(). But that seems strange, imho. The semantics openat2() has might be very useful for new system calls as well which might also want to support parts of AT_* flags (see fsinfo()). So we either end up adding new AT_* flags mirroring the new RESOLVE_* flags or we end up adding new RESOLVE_* flags mirroring parts of AT_* flags. And if that's a possibility I vote for RESOLVE_* flags going forward. The have better naming too imho. An argument against this could be that we might end up causing more confusion for userspace due to yet another set of flags. But maybe this isn't an issue as long as we restrict RESOLVE_* flags to new syscalls. When we introduce a new syscall userspace will have to add support for it anyway. > > If so, should we comment them as being deprecated in the header file? And > should they be in linux/fcntl.h rather than linux/openat2.h? > > Also: > > (*) It should be noted that the RESOLVE_* flags are not a superset of the > AT_* flags (there's no equivalent of AT_NO_AUTOMOUNT for example). That's true but it seems we could just add e.g. RESOLVE_NO_AUTOMOUNT as soon as we have a new syscall showing up that needs it or we have an existing syscall (e.g. openat2()) that already uses RESOLVE_* flags and needs it? > > (*) It has been suggested that AT_SYMLINK_NOFOLLOW should be the default, but > only RESOLVE_NO_SYMLINKS exists. I'd be very much in favor of not following symlinks being the default. That's usually a source of a lot of security issues. And since no kernel with openat2() has been released there's still time to switch it and with openat2() being a new syscall it won't hurt if it has new semantics; I mean it deviates from openat() - intentionally - already. Christian
