linux-kernel - Re: [GIT PULL] cifs/smb3 client fixes

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: <CAHk-=wjxmDks6CS41PCy_BZG70pjAhcPBV_7ga8kSJySvvDezQ@mail.gmail.com>
Date:   Tue, 31 Aug 2021 10:43:29 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steve French <smfrench@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>
Subject: Re: [GIT PULL] cifs/smb3 client fixes

On Tue, Aug 31, 2021 at 10:09 AM Steve French <smfrench@...il.com> wrote:
>
>   So if you are ok with renaming the client dir and module
> name - we can gradually stop using the word/name "cifs" except for the
> parts of code which really are needed to access the (unfortunately
> hundreds of millions of) very old devices which require SMB1 ("CIFS").

I'm ok with directory renames, git handles it all well enough that the
pain should be fairly minimal.

I'd ask for that to be done during a fairly calm cycle, though, when
there isn't a lot pending, so that any rename conflicts will be
minimized.

> We could even build two versions of the module "smb3.ko" which does not
> include support for the less secure legacy dialects and "cifs.ko" which does
> include it.   Is there a precedent for something similar.

I'm not sure there is precedent for that, but that's not a huge issue per se.

Whether it's actually worth it having two separate modules, I don't know.

That said, I'm not entirely enamoured with the name "smb" as a module
(or directory) name, to put it lightly.

Part of it is that it can mean "system management bus" too, although
in the kernel we happily universally (?) use "smbus" for that.

But a big part of it is exactly the history of random different names,
which means that I'd like any new name to be more explicit than a TLA
that has been mis-used for so long.

So yes, we have "fs/nfs/", but I'd rather _not_ have "fs/smb/".

They may superficially look entirely equivalent - but one of them has
had a consistent name that is unambiguous and has no horrible naming
history. The other has not.

> Do you have any objections to me renaming the client's source
> directory to "fs/smb3" (or fs/smb) and fs/smb3_common ...?

So no objections to the rename per se, but can we please use a more
specific name that is *not* tainted by history?

I'll throw out two suggestions, but they are just that: (a) "smbfs" or
(b) "smb-client".

I think "smbfs" has the nice property of making it clear that this is
just the filesystem part of the smb protocols - that otherwise cover a
lot of other things too (at least historically printers, although I
have no idea how true that is any more).

And "smb-client" as a name is in no way great, but at least it's not
just a TLA, and from a naming standpoint it would match the
"smb-common" thing (although I guess you used an underscore, not a
dash).

Again - those are just two random suggestions, and I'm not married to
either of them, I just really don't like just that "smb" because of
all the historical naming baggage.

So if we rename, we should rename it to something new and slightly
more specific than what we used to have.

I'd rather have a module called "smbfs.ko" (or "smb-fs.ko" or
"smb-client.ko" etc) than "smb.ko".

And no, I wouldn't want it to be called "smb3" either. Because it
clearly does cifs/smb1 and smb2 too (even if people would obviously
like to deprecate at least the older parts).

Hmm? Is there some unambiguous name that is in use by the smb
community and would work?

                 Linus