[Top][All Lists]

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

Re: fstatat + AT_NO_AUTOMOUNT

From: Pádraig Brady
Subject: Re: fstatat + AT_NO_AUTOMOUNT
Date: Mon, 7 Mar 2022 17:33:22 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0

On 07/03/2022 17:11, Paul Eggert wrote:
On 3/7/22 07:02, Pádraig Brady wrote:
When looking into
which discussed statx + AT_NO_AUTOMOUNT,
I was wondering about the fstatat changes in
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.

That commit replaced some stat() calls with fstatat().

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?

Yes this is surprising.
I'm only going by the fstatat man page,
but I also see correlation of the issue in for e.g.:

I've yet to dig into the original kernel discussions and implementation.

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.

Yes I expect we'll have different treatments in different places.
Attached is an adjustment for ln in coreutils at least.

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.

I see unlinkat() uses lstatat(),
and in that context it would be better to specify AT_NO_AUTOMOUNT
I think since we're operating on the dir not the file itself.

Also agreed that eliminating these aliases
would avoid at least this particular ambiguity.

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?

Yes the flag is not mentioned wrt that call,
I've yet to audit kernel code.


Attachment: ln-no-automount.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]