linux-kernel - Re: [V9fs-developer] [PATCH 2/6] Don't assume UID 0 attach

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] [day] [month] [year] [list]

Date:   Sun, 18 Dec 2022 13:59:29 -0600
From:   evanhensbergen@...oud.com
To:     asmadeus@...ewreck.org
Cc:     Latchesar Ionkov <lucho@...kov.net>,
        Christian Schoenebeck <linux_oss@...debyte.com>,
        linux-kernel@...r.kernel.org, Ron Minnich <rminnich@...il.com>,
        linux-fsdevel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH 2/6] Don't assume UID 0 attach

Can you send me your xfstest invocation formulas and I’ll add them to my regression tests.

Yeah, I was torn on this merge window or next - the more complicated patches here are really fixes for things that are kinda broken in the code — so they might even be -rc candidate patches.  Most of them only effect cache mode, which isn’t default — so its probably low-risk, but I know the preference is for things to have had longer in the review cycle to marinate.

The simple ones probably could go into this merge window, but I leave it up to you since you’ve been carrying the maintainer mantle — and my PGP key and kernel.org repos need to be re-established in the web of trust, but mainly because you’re active maintainer here.

I’ll keep crunching and send out the new patch set by the end of the day regardless.

     -eric



> On Dec 18, 2022, at 1:49 PM, asmadeus@...ewreck.org wrote:
> 
> evanhensbergen@...oud.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