linux-kernel - Re: RFC: Revert move default dialect from CIFS to to SMB3

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: <CAH2r5msWDXzwbFPtUHCKbqHrEBTsvw5eaTayj5RkdgYCLM5nAQ@mail.gmail.com>
Date:   Thu, 31 Aug 2017 19:29:42 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
        Pavel Shilovsky <pshilov@...rosoft.com>,
        Jeff Layton <jlayton@...hat.com>
Subject: Re: RFC: Revert move default dialect from CIFS to to SMB3

Yes - updating the parsing slightly and printks as suggested makes sense

Some additional warning messages in the userspace helper (adding Jeff
Layton), mount.cifs can also help.

I also have an experimental set of patches to allow multi-dialect
negotiation with at least three of the acceptable dialects
(smb2.1/smb3/smb3.02) which will help, but complicate secure dialect
validation ("validate negotiate") but that will have to wait till next
release.

On Thu, Aug 31, 2017 at 7:12 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Aug 31, 2017 at 2:36 PM, Thorsten Leemhuis <linux@...mhuis.info> wrote:
>> Lo! To give a bit more background to this (the mail I reply to was the
>> first I sent with git send-email and I missed some details): Maybe I'm
>> over stretching my abilities/position as regression tracker with this
>> RFC for a revert, but I hope it at least triggers a discussion if such a
>> revert should be done or not.
>
> I don't think that a revert is appropriate.
>
> But perhaps just a single printk() or something if the user does *not*
> specify the version explicitly? Just saying something like
>
>   We used to default to 1.0, we now default to 3.0, if you want old
> defaults, use "vers=1.0"
>
> Oh, looking at that version parsing code, I think we also need to fix
> that legacy "ver=1" thing (ver without the 's') which now silently
> ignores "ver=1" as being the "default", even though it's not.
>
> I do *not* believe that "default to version 1" is acceptable.
>
>                 Linus



-- 
Thanks,

Steve