What about adding AT_NO_AUTOMOUNT analogue to openat2?

What about adding AT_NO_AUTOMOUNT analogue to openat2?

[Askar Safin]

What about adding stat's AT_NO_AUTOMOUNT analogue to openat2?


==
Askar Safin
https://github.com/safinaskar

Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On 2020-04-11, Askar Safin <safinaskar@mail.ru> wrote:
> What about adding stat's AT_NO_AUTOMOUNT analogue to openat2?

There isn't one. I did intend to add RESOLVE_NO_AUTOMOUNTS after openat2
was merged -- it's even mentioned in the commit message -- but I haven't
gotten around to it yet. The reason it wasn't added from the outset was
that I wasn't sure if adding it would be as simple as the other
RESOLVE_* flags.

Note that like all RESOLVE_* flags, it would apply to all components so
it wouldn't be truly analogous with AT_NO_AUTOMOUNT (though as I've
discussed at length on this ML, most people do actually want the
RESOLVE_* semantics). But you can emulate the AT_* ones much more easily
with RESOLVE_* than vice-versa).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?

[Al Viro]

On Sat, Apr 11, 2020 at 04:02:36PM +1000, Aleksa Sarai wrote:
> On 2020-04-11, Askar Safin <safinaskar@mail.ru> wrote:
> > What about adding stat's AT_NO_AUTOMOUNT analogue to openat2?
> 
> There isn't one. I did intend to add RESOLVE_NO_AUTOMOUNTS after openat2
> was merged -- it's even mentioned in the commit message -- but I haven't
> gotten around to it yet. The reason it wasn't added from the outset was
> that I wasn't sure if adding it would be as simple as the other
> RESOLVE_* flags.
> 
> Note that like all RESOLVE_* flags, it would apply to all components so
> it wouldn't be truly analogous with AT_NO_AUTOMOUNT (though as I've
> discussed at length on this ML, most people do actually want the
> RESOLVE_* semantics). But you can emulate the AT_* ones much more easily
> with RESOLVE_* than vice-versa).

Er...  Not triggering automount on anything but the last component means
failing with ENOENT.  *All* automount points are empty and are bloody
well going to remain such, as far as I'm concerned.

Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?

[Aleksa Sarai]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On 2020-04-11, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sat, Apr 11, 2020 at 04:02:36PM +1000, Aleksa Sarai wrote:
> > On 2020-04-11, Askar Safin <safinaskar@mail.ru> wrote:
> > > What about adding stat's AT_NO_AUTOMOUNT analogue to openat2?
> > 
> > There isn't one. I did intend to add RESOLVE_NO_AUTOMOUNTS after openat2
> > was merged -- it's even mentioned in the commit message -- but I haven't
> > gotten around to it yet. The reason it wasn't added from the outset was
> > that I wasn't sure if adding it would be as simple as the other
> > RESOLVE_* flags.
> > 
> > Note that like all RESOLVE_* flags, it would apply to all components so
> > it wouldn't be truly analogous with AT_NO_AUTOMOUNT (though as I've
> > discussed at length on this ML, most people do actually want the
> > RESOLVE_* semantics). But you can emulate the AT_* ones much more easily
> > with RESOLVE_* than vice-versa).
> 
> Er...  Not triggering automount on anything but the last component means
> failing with ENOENT.  *All* automount points are empty and are bloody
> well going to remain such, as far as I'm concerned.

I wasn't suggesting that RESOLVE_NO_AUTOMOUNTS would unmask whatever is
on the underlying filesystem -- I agree that would be completely insane.

It would just give you -EXDEV (or perhaps -EREMOTE) if you walk into an
automount (the same logic as with the other RESOLVE_NO_* flags). We
could make it -ENOENT if you prefer, but that means userspace can't tell
the difference between it hitting an automount and the target actually
not existing.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: What about adding AT_NO_AUTOMOUNT analogue to openat2?

[Florian Weimer]

* Aleksa Sarai:

> It would just give you -EXDEV (or perhaps -EREMOTE) if you walk into an
> automount (the same logic as with the other RESOLVE_NO_* flags). We
> could make it -ENOENT if you prefer, but that means userspace can't tell
> the difference between it hitting an automount and the target actually
> not existing.

Maybe there's a better way to show the difference to userspace
involving something related to O_PATH?