Re: fstatat + AT_NO_AUTOMOUNT

[Paul Eggert]

On 3/7/22 07:02, Pádraig Brady wrote:
> When looking into https://bugs.gnu.org/54286
> which discussed statx + AT_NO_AUTOMOUNT,
> I was wondering about the fstatat changes in
> https://github.com/coreutils/coreutils/commit/571f63f50
> and whether some of those should also specify AT_NO_AUTOMOUNT?

I'm a bit lost, as I see no mention of fstatat in that commit.

I was not aware of AT_NO_AUTOMOUNT until now, and am surprised about it. 
POSIX says that stat(f,s) is supposed to be equivalent to 
fstatat(AT_FDCWD,f,s,0). But if I understand things correctly, this 
isn't true on GNU/Linux: you must pass AT_NO_AUTOMOUNT instead of 0. I 
assume that this departure from POSIX was intentional, but even so it's 
pretty confusing. Could you explain why AT_NO_AUTOMOUNT wasn't made the 
default for fstatat?

I suppose we first need to audit all of Gnulib's uses of fstatat and 
statx to see whether they need AT_NO_AUTOMOUNT added. Once we're done 
with that we can turn to Coreutils.

For example, what about the calls to fstatat in gnulib/lib/openat.h? Are 
statat and lstatat intended as convenient aliases for fstatat, or as 
directory-fd extensions to stat and lstat? If the former, they should be 
left alone; if the latter, they need AT_NO_AUTOMOUNT. Or perhaps it 
would be better to eliminate them and replace them with calls to 
fstatat, since we'll need to decide on a call-by-call basis anyway.

Another example: what about the fstatat call in gnulib/lib/fchmodat.c? I 
suppose we should not add AT_NO_AUTOMOUNT there, under the theory that 
GNU/Linux faccessat does not do the equivalent of AT_NO_AUTOMOUNT. Is 
that right?