public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
Date: Mon, 19 Dec 2022 04:49:35 +0900	[thread overview]
Message-ID: <Y59uz0aeuoLMU9W8@codewreck.org> (raw)
In-Reply-To: <864E1007-CBCF-40C7-B438-A76C3065AFC9@icloud.com>

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

  parent reply	other threads:[~2022-12-18 19:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17 18:52 [PATCH] Improve 9p performance for read operations Eric Van Hensbergen
2022-12-17 18:52 ` [PATCH 1/6] Adjust maximum MSIZE to account for p9 header Eric Van Hensbergen
2022-12-18 14:49   ` Christian Schoenebeck
     [not found]     ` <CAFkjPTmoQvzaSsSOAgM9_0+knudWsdi8=TnMOTXZj05hT6tneQ@mail.gmail.com>
     [not found]       ` <51FD8D16-4070-4DCF-AEB5-11640A82762E@icloud.com>
     [not found]         ` <CAP6exY+BF+1fjjUKX20vvbTZXiZ2gxUN3zc8+ZaHTY-aX6fRFQ@mail.gmail.com>
2022-12-18 19:46           ` asmadeus
2022-12-18 19:52             ` evanhensbergen
2022-12-17 18:52 ` [PATCH 2/6] Don't assume UID 0 attach Eric Van Hensbergen
2022-12-18  0:07   ` asmadeus
2022-12-18  1:05     ` evanhensbergen
     [not found]       ` <864E1007-CBCF-40C7-B438-A76C3065AFC9@icloud.com>
2022-12-18 19:49         ` asmadeus [this message]
2022-12-18 19:59           ` [V9fs-developer] " evanhensbergen
2022-12-17 18:52 ` [PATCH 3/6] Expand setup of writeback cache to all levels Eric Van Hensbergen
2022-12-17 18:52 ` [PATCH 4/6] Consolidate file operations and add readahead and writeback Eric Van Hensbergen
2022-12-17 20:49   ` kernel test robot
2022-12-17 21:50   ` kernel test robot
2022-12-17 18:52 ` [PATCH 5/6] Remove unnecessary superblock flags Eric Van Hensbergen
2022-12-17 18:52 ` [PATCH 6/6] allow disable of xattr support on mount Eric Van Hensbergen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y59uz0aeuoLMU9W8@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=evanhensbergen@icloud.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=rminnich@gmail.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox