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: <CAH2r5mt72NYan9q8MR5H8cNkYzT4jn1ZM1f3jp5V-fDs2cyB-A@mail.gmail.com>
Date:   Tue, 31 Aug 2021 13:06:41 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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 12:43 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

Given likely movement of various common server/client functions into
cifs_common in the short term - we can delay renaming "fs/cifs"
(and fs/cifs_common) to e.g. "fs/smbfs" to 5.16 or 5.17


> > 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.

<snip>

> > 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).

"smbfs" would likely be fine and I can bounce the idea around
others on Samba team etc.  And yes you are right, the broader
"SMB family of protocols" covers a lot of other functions
(from systems management, DCE/RPC, clustering, change notification,
named pipes, global name space ... not just files and printers) so "smbfs"
as a name for the client fs module going forward may be a bit less confusing.

> 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".

That should be easy enough (IIRC FreeBSD called their
module "smbfs), but presumably wait until 5.16 or 5.17
to lessen merge conflicts etc.


-- 
Thanks,

Steve