Please pull the following changes since commit
e22ce8eb631bdc47a4a4ea7ecf4e4ba499db4f93:
Linux 5.14-rc7 (2021-08-22 14:24:56 -0700)
are available in the Git repository at:
git://git.samba.org/sfrench/cifs-2.6.git tags/5.15-rc-smb3-fixes-part1
for you to fetch changes up to 3998f0b8bc49ec784990971dc1f16bf367b19078:
cifs: Do not leak EDEADLK to dgetents64 for
STATUS_USER_SESSION_DELETED (2021-08-25 16:08:38 -0500)
----------------------------------------------------------------
11 cifs/smb3 client fixes:
- mostly restructuring to allow disabling less secure algorithms (this
will allow eventual removing rc4 and md4 from general use in the
kernel)
- 4 fixes, including 2 for stable
- enable r/w support with fscache and cifs.ko
Am working on a larger set of changes (the usual ... multichannel,
auth and signing improvements), but wanted to get these in earlier to
reduce chance of merge conflicts
later in the merge window.
----------------------------------------------------------------
Ding Hui (1):
cifs: fix wrong release in sess_alloc_buffer() failed path
Len Baker (1):
CIFS: Fix a potencially linear read overflow
Ronnie Sahlberg (4):
cifs: remove support for NTLM and weaker authentication algorithms
cifs: fork arc4 and create a separate module for it for cifs and
other users
cifs: create a MD4 module and switch cifs.ko to use it
cifs: Do not leak EDEADLK to dgetents64 for STATUS_USER_SESSION_DELETED
Shyam Prasad N (1):
cifs: enable fscache usage even for files opened as rw
Steve French (4):
smb3: fix posix extensions mount option
oid_registry: Add OIDs for missing Spnego auth mechanisms to Macs
cifs: cifs_md4 convert to SPDX identifier
cifs: add cifs_common directory to MAINTAINERS file
MAINTAINERS | 1 +
fs/Kconfig | 7 ++
fs/Makefile | 1 +
fs/cifs/Kconfig | 30 -------
fs/cifs/cifs_debug.c | 11 ---
fs/cifs/cifs_swn.c | 2 -
fs/cifs/cifs_unicode.c | 9 +-
fs/cifs/cifsencrypt.c | 89 +-------------------
fs/cifs/cifsfs.c | 8 --
fs/cifs/cifsglob.h | 32 +------
fs/cifs/cifspdu.h | 28 -------
fs/cifs/cifsproto.h | 10 ---
fs/cifs/cifssmb.c | 107 +-----------------------
fs/cifs/connect.c | 32 -------
fs/cifs/file.c | 15 +++-
fs/cifs/fs_context.c | 25 ++----
fs/cifs/fs_context.h | 3 -
fs/cifs/fscache.c | 41 +++++++--
fs/cifs/fscache.h | 23 ++++++
fs/cifs/inode.c | 6 ++
fs/cifs/readdir.c | 23 +++++-
fs/cifs/sess.c | 257
+--------------------------------------------------------
fs/cifs/smb2maperror.c | 1 -
fs/cifs/smbencrypt.c | 139 +++----------------------------
fs/cifs_common/Makefile | 7 ++
fs/cifs_common/arc4.h | 23 ++++++
fs/cifs_common/cifs_arc4.c | 87 +++++++++++++++++++
fs/cifs_common/cifs_md4.c | 197 +++++++++++++++++++++++++++++++++++++++++++
fs/cifs_common/md4.h | 27 ++++++
include/linux/oid_registry.h | 7 ++
30 files changed, 485 insertions(+), 763 deletions(-)
create mode 100644 fs/cifs_common/Makefile
create mode 100644 fs/cifs_common/arc4.h
create mode 100644 fs/cifs_common/cifs_arc4.c
create mode 100644 fs/cifs_common/cifs_md4.c
create mode 100644 fs/cifs_common/md4.h
--
Thanks,
Steve
The pull request you sent on Mon, 30 Aug 2021 00:48:32 -0500:
> git://git.samba.org/sfrench/cifs-2.6.git tags/5.15-rc-smb3-fixes-part1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9c849ce86e0fa93a218614eac562ace44053d7ce
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Sun, Aug 29, 2021 at 10:48 PM Steve French <[email protected]> wrote:
>
> - mostly restructuring to allow disabling less secure algorithms (this
> will allow eventual removing rc4 and md4 from general use in the
> kernel)
Well, you should probably have mentioned that you already started on
this by removing LANMAN support.
I'm sincerely hoping nobody used or depended on that old garbage in
this day and age any more.
Anyway, entirely unrelated question: you pretty much interchangeably
use "cifs" or "smb3" for the filesystem, as shown once more by the
commit messages here (but also the subject line).
The filesystem directory is called "cifs", and I've taken to use that
in my "Pull cifs updates" thing from you to just avoiding the
confusion.
And now we have ksmbd (yup, I just merged that pull request too), so
we have a "cifs client" and a "smb server". Aaarrgh.
I understand that some people may care about the name, may care about
"smb2 vs smb3", or whatever. But I have to admit finding it a bit
annoying how the code and the directory layout uses these different
terms pretty much randomly with no real apparent logic.
Somehow the NFS people had no problem completely changing everything
about their protocols and then still calling the end result "nfs
client" vs "nfs server".
Oh well. I'm assuming it's not going to change, and it's not really a
problem, I just wanted to mention my frustration about how clear as
mud the naming is.
Linus
On Tue, Aug 31, 2021 at 11:40 AM Linus Torvalds
<[email protected]> wrote:
>
> On Sun, Aug 29, 2021 at 10:48 PM Steve French <[email protected]> wrote:
> >
> > - mostly restructuring to allow disabling less secure algorithms (this
> > will allow eventual removing rc4 and md4 from general use in the
> > kernel)
>
> Well, you should probably have mentioned that you already started on
> this by removing LANMAN support.
>
> I'm sincerely hoping nobody used or depended on that old garbage in
> this day and age any more.
>
> Anyway, entirely unrelated question: you pretty much interchangeably
> use "cifs" or "smb3" for the filesystem, as shown once more by the
> commit messages here (but also the subject line).
>
> The filesystem directory is called "cifs", and I've taken to use that
> in my "Pull cifs updates" thing from you to just avoiding the
> confusion.
>
> And now we have ksmbd (yup, I just merged that pull request too), so
> we have a "cifs client" and a "smb server". Aaarrgh.
>
> I understand that some people may care about the name, may care about
> "smb2 vs smb3", or whatever. But I have to admit finding it a bit
> annoying how the code and the directory layout uses these different
> terms pretty much randomly with no real apparent logic.
>
> Somehow the NFS people had no problem completely changing everything
> about their protocols and then still calling the end result "nfs
> client" vs "nfs server".
>
> Oh well. I'm assuming it's not going to change, and it's not really a
> problem, I just wanted to mention my frustration about how clear as
> mud the naming is.
> Linus
I (and many at Microsoft and in Samba team etc.) also have a strong
desire to stop
using the word "CIFS" as it has been associated with some very high profile
attacks, and with the introduction of SMB2.1 support (which was far more
secure) in 2009 no one should be using the very old CIFS dialect
(aka "SMB1" dialect). 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").
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.
Note that with the introduction of various security features
in SMB3 (then even more security features in SMB3.1.1) it seems like it seemed
confusing to users to tell them "mount -t cifs ..." which was why I
added support
for "mount -t smb3 (to cifs.ko) in the 4.18 kernel/ but I also
would strongly like to
stop using the word "cifs" in module name going forward, even if it does cause
a little bit of extra work for distros (most of which could be handled
in the mount
helper in any case)
If no objections, we can start moving most things on
the client to "smb.ko" rather than "cifs.ko" ...
Do you have any objections to me renaming the client's source
directory to "fs/smb3"
(or fs/smb) and fs/smb3_common ...?
--
Thanks,
Steve
On Tue, Aug 31, 2021 at 10:09 AM Steve French <[email protected]> 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
On Tue, Aug 31, 2021 at 12:43 PM Linus Torvalds
<[email protected]> wrote:
>
> On Tue, Aug 31, 2021 at 10:09 AM Steve French <[email protected]> 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
On Tue, Aug 31, 2021 at 1:06 PM Steve French <[email protected]> wrote:
> On Tue, Aug 31, 2021 at 12:43 PM Linus Torvalds
> <[email protected]> wrote:
> >
> > On Tue, Aug 31, 2021 at 10:09 AM Steve French <[email protected]> wrote:
<snip>
> > 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.
<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".
Due to git history for fs/smbfs directory (from many, many years ago) rename
to "fs/smbfs" could be more confusing. So alternative suggestion which
I implemented
was rename the source directory from fs/cifs to "fs/smbfs_client." I
will send a P/R
for that since it is fairly quiet right now. If you would prefer that
we wait for a future
release that is fine too, but seems like low risk now and might reduce
future confusion in
the future (to rename the source directory).