linux-kernel - Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat

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

Message-ID: <20190902152524.GA4964@kroah.com>
Date:   Mon, 2 Sep 2019 17:25:24 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Valdis Klētnieks <valdis.kletnieks@...edu>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of
 fat/vfat

On Mon, Sep 02, 2019 at 12:35:25AM -0700, Christoph Hellwig wrote:
> On Sat, Aug 31, 2019 at 06:25:21AM -0400, Valdis Klētnieks wrote:
> > On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> > 
> > > Since when did Linux kernel submissions become "show me a better patch"
> > > to reject something obviously bad?
> > 
> > Well, do you even have a *suggestion* for a better idea?  Other than "just rip
> > it out"?  Keeping in mind that:
> 
> The right approach in my opinion is to start submitting patches to fs/fat
> to add exfat support.  But more importantly it is to first coordinate
> with other stakeholder most importantly the fs/fat/ maintainer and the
> dosfstools maintainers as our local experts for fat-like file systems
> instead of shooting from the hip.

I dug up my old discussion with the current vfat maintainer and he said
something to the affect of, "leave the existing code alone, make a new
filesystem, I don't want anything to do with exfat".

And I don't blame them, vfat is fine as-is and stable and shouldn't be
touched for new things.

We can keep non-vfat filesystems from being mounted with the exfat
codebase, and make things simpler for everyone involved.

> > Now, if what you want is "Please make it so the fat16/fat32 code is in separate
> > files that aren't built unless requested", that's in fact doable and a
> > reasonable request, and one that both doesn't conflict with anything other
> > directions we might want to go, and also prepares the code for more easy
> > separation if it's decided we really do want an exfat-only module.
> 
> No.  Assuming we even want the current codebase (which only you and
> Greg seem to think so), that fat16/32 code simply has to go.

I don't think it should stay in there, let's drop it from the exfat
code.

As for the other issues discussed here in this thread:
  - yes, putting a filesystem in staging is extra work overall, but for
    projects that want to do that extra work, wonderful, do it here in a
    common place for everyone to work on together.
  - working on in a common place is what we need for exfat right now,
    as there are 40+ different github forks and no one knows which one
    is "correct" or most up to date.  We needed to decide on "one" and
    here it is, the in-tree one.
  - for vfs developers who don't want to even look at the crud in
    staging (remember, it's TAINT_CRAP if you load code from here),
    don't.  Just keep on your own normal development cycles and if you
    break any staging code, it's fine, I will fix it up no complaints at
    all.
  - staging code is for crappy code to get fixed up.  If it isn't
    constantly updated, it will be dropped.  Yes, there is code in there
    that probably should be dropped now as I haven't done a sweep in a
    few years, suggestions always welcome.  There is also code that
    needs to be moved out with just a bit more work needed (greybus,
    comedi, speakup, etc.)  Some of that is underway right now.

thanks,

greg k-h