Re: RFC: Fixing net/sunrpc/cache.c: cache_listeners_exist() function for rogue process reading a 'channel' file

[Bruce Fields <bfields@fieldses.org>]

On Thu, Jul 25, 2019 at 12:48:31PM -0400, Dave Wysochanski wrote:
> 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)

Assuming we've checked that none of those random processes are opening
for write, that sounds reasonable to me.

> 2) in addition to or in place of #1, track calls to cache_poll()

I'm not sure how this would work.  What exactly would be the rule, and
how would we document the required behavior for somebody working on the
userland (rpc.mountd) side?

> 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.

It might be worth at least sketching out a design to get an idea how
complicated it would be.  Agreed that backwards compatibility would be
the annoying part.

--b.