linux-kernel - Re: Do we really need d_weak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgNAki1SYjr7-6g-i3shGjQRjwy81gS0QisfZRy-x-bHFtXmA@mail.gmail.com>
Date:   Thu, 24 Aug 2017 13:03:28 +0200
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     NeilBrown <neilb@...e.com>
Cc:     Ian Kent <ikent@...hat.com>, Jeff Layton <jlayton@...hat.com>,
        Trond Myklebust <trondmy@...marydata.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mkoutny@...e.com" <mkoutny@...e.com>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Do we really need d_weak_revalidate???

Hi Neil,

On 24 August 2017 at 06:07, NeilBrown <neilb@...e.com> wrote:
> On Wed, Aug 23 2017, Ian Kent wrote:
>
>>
>> That inconsistency has bothered me for quite a while now.
>>
>> It was carried over from the autofs module behavior when automounting
>> support was added to the VFS. What's worse is it prevents the use of
>> the AT_NO_AUTOMOUNT flag from working properly with fstatat(2) and with
>> statx().
>>
>> There is some risk in changing that so it does work but it really does
>> need to work to enable userspace to not trigger an automount by using
>> this flag.
>>
>> So that's (hopefully) going to change soonish, see:
>> http://ozlabs.org/~akpm/mmotm/broken-out/autofs-fix-at_no_automount-not-being-honored.patch
>>
>> The result should be that stat family calls don't trigger automounts except
>> for fstatat(2) and statx() which will require the AT_NO_AUTOMOUNT flag.
>>
>
> oooh, yes.  That's much better - thanks.
>
> We should make sure that change gets into the man pages...
>
> First however, we should probably correct the man page!
> stat.2 says:
>
>
>   NOTES
>        On Linux, lstat() will generally not trigger  automounter
>        action,  whereas  stat()  will  (but  see  the description of
>        fstatat() AT_NO_AUTOMOUNT fag, above).
>
> which is wrong: lstat and stat treat automounts the same.
> @Michael: do you recall why you inserted that text?  The commit message
> in commit 1ef5b2805471 ("stat.2: Cosmetic reworking of timestamp
> discussion in NOTES") is not very helpful.

That commit really was just cosmetic changes. The change that
introduced the text was 82d2be3d9d66b7, based on a note from Peter
Anvin:

[[
    > > Additionally, you may want to make a note in the stat/lstat man page tha
t on
    > > Linux, lstat(2) will generally not trigger automounter action, whereas
    > > stat(2) will.
    >
    > I don't understand this last piece.  Can you say some more.  (I'm not
    > familiar with automounter details.)

    An automounter (either an explicit one, like autofs, or an implicit
    one, such as are used by AFS or NFSv4) is something that triggers
    a mount when something is touched.

    However, it's undesirable to automount, say, everyone's home
    directory just because someone opened up /home in their GUI
    browser or typed "ls -l /home".  The early automounters simply
    didn't list the contents until you accessed it by name;
    this is still the case when you can't enumerate a mapping
    (say, all DNS names under /net).  However, this is extremely
    inconvenient, too.

    The solution we ended up settling on is to create something
    that looks like a directory (i.e. reports S_IFDIR in stat()),
    but behaves somewhat like a symlink.  In particular, when it is
    accessed in a way where a symlink would be dereferenced,
    the automount triggers and the directory is mounted.  However,
    system calls which do *not* cause a symlink to be dereferenced,
    like lstat(), also do not cause the automounter to trigger.
    This means that "ls -l", or a GUI file browser, can see a list
    of directories without causing each one of them to be automounted.

            -hpa
]]

Cheers,

Michael

> I propose correcting to
>
>   NOTES:
>       On Linux, lstat() nor stat() act as though AT_NO_AUTOMOUNT was set
>       and will not trigger automounter action for direct automount
>       points, though they may (prior to 4.14) for indirect automount
>       points.
>
>
> The more precise details, that automount action for indirect automount
> points is not triggered when the 'browse' option is used, is probably
> not necessary.
>
> Ian: if you agree with that text, and Michael doesn't provide alternate
> evidence, I'll submit a formal patch for the man page.... or should we
> just wait until the patch actually lands?
>
> Thanks,
> NeilBrown
>



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/