Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <22770aa2024c1dab1b7eaded1eed9957963413fb.camel@redhat.com>
Subject: RFC: Fixing net/sunrpc/cache.c: cache_listeners_exist() function
 for rogue process reading a 'channel' file
From:   Dave Wysochanski <dwysocha@redhat.com>
To:     NeilBrown <neilb@suse.com>, Bruce Fields <bfields@fieldses.org>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Date:   Thu, 25 Jul 2019 12:48:31 -0400
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

Neil, Bruce, and others,

I want to see if we can improve cache_listeners_exist() to not be
fooled at all by a random process reading a 'channel' file.  Prior
attempts have been made and Neil your most recent commit mitigated the
effects however doesn't really solve it completely:
9d69338c8c5f "sunrpc/cache: handle missing listeners better"

Here are a couple approaches, based on my understanding of the
interface and what any legitimate "user of the channel files" (aka
daemons or userspace programs, most if not all live in nfs-utils) do in
practice:
1) rather than tracking opens for read, track opens for write on the
channel file (i.e. the 'readers' member in cache_detail)
2) in addition to or in place of #1, track calls to cache_poll()

Basically the above would create a 'cache_daemon_exists()' function in
place of the existing 'cache_listeners_exist()' and then add some
further logic to it.  Do you think that is a valid approach or do you
see problems with it?

Because this keeps coming up in one shape or form and is hard to
troubleshoot when it occurs, I think we should fix this once and for
all so I'm looking for feedback on approaches.  I thought of going down
the road of a more elaborate daemon / kernel registration but that
would require carefully making sure we have backward compatibility when
variants of nfs-utils and kernel are installed.  I think it may be
worth looking at less invasive approaches first such as the above, but
am open to feedback.

Thanks.