Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 19 Dec 2022 04:49:35 +0900
From:   asmadeus@codewreck.org
To:     evanhensbergen@icloud.com
Cc:     Latchesar Ionkov <lucho@ionkov.net>, linux_oss@crudebyte.com,
        linux-kernel@vger.kernel.org, Ron Minnich <rminnich@gmail.com>,
        linux-fsdevel@vger.kernel.org, v9fs-developer@lists.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH 2/6] Don't assume UID 0 attach
Message-ID: <Y59uz0aeuoLMU9W8@codewreck.org>
References: <20221217185210.1431478-1-evanhensbergen@icloud.com>
 <20221217185210.1431478-3-evanhensbergen@icloud.com>
 <Y55Z2DwZgRG+9zW3@codewreck.org>
 <3343B7A9-2D1D-4A41-859E-B04AF90152FA@icloud.com>
 <864E1007-CBCF-40C7-B438-A76C3065AFC9@icloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <864E1007-CBCF-40C7-B438-A76C3065AFC9@icloud.com>
Precedence: bulk

evanhensbergen@icloud.com wrote on Sun, Dec 18, 2022 at 10:32:57AM -0600:
> Okay, reproduced the error you suspected on the patch.  It’s kind of a
> pain because the code as is won’t work unless I’m running the file
> server as root and changing all the servers to ignore requests seems
> off.  It also occurred to me that having a root R/W write back could
> be a security vulnerability.  I tried patching it with
> dfltuid/dfltgid, but only root can override the modes so that doesn’t
> work.
> 
> Since I have the better write back fix testing okay, we could drop
> this patch from the series and I could just focus on getting that
> patch ready (which I should be able to do today).  It does seem to
> work with the python test case you gave, so it doesn’t have the same
> issues.
> 
> Thoughts?

That sounds good to me, thanks!

I haven't had time to look at the other patches in detail but they look
good to me in principle.
I'll try to find time to run some xfstests this week to check for
regressions with the other patches (I don't have any list, so run some
before/after with qemu in cache=mmap/loose modes perhaps?) and we can
submit them next merge window unless you're in a hurry.
Some are obvious fixes (not calling in fscache code in loose mode) and
could get in faster but I don't think we should rush e.g. option
parsing... Well that probably won't get much tests in -next, I'll leave
that up to you.

Do you (still?) have a branch that gets merged in linux-next, or shall I
take the patches in for that, or do you want to ask Stefen?
(I should probably just check myself, but it's 5am and I'll be lazy)

-- 
Dominique