Bug 1011621

Please to re-assign the issue to kernel folks.

It works fine with previous kernel kernel-3.10.11-200.fc19.x86_64. It does not work on the latest kernel-3.11.1-200.fc19.x86_64. I have booted 3.10.11 and the share was successfully mounted.

The evil 3.11.1 kernel has deprived of our samba shares.

A not so recommended temporary workaround:

# yum remove kernel-3.11.1-200.fc19.x86_64
# yum remove kernel-devel-3.11.1-200.fc19.x86_64
# grub2-mkconfig -o /boot/grub2/grub.cfg
# grub2-install /dev/sda
# yum install yum-plugin-versionlock.noarch
# yum versionlock add kernel-3.10.11-200.fc19
# yum versionlock add kernel-devel-3.10.11-200.fc19.x86_64
# yum check-update
<empty>

Probably fallout from the auth overhaul and cleanup that went into 3.11. We'll likely need to add some special-casing to allow the client to use plaintext passwords when the server doesn't send a legacy NEGOTIATE response.

The best thing UI-wise, IMO would be to add a sec=plain mount option instead of having to do this weirdo fiddling with the SecurityFlags, but I'm not sure Steve will accept that solution.

Even though Samba server tries to discourage you from plaintext (for good reason), and other servers may not even support plaintext at all, it looks like plaintext will still work to Samba with current kernels.  

On 3.12-rc2 (and 3.11) I was able to send a plaintext password as follows:

On server:
a) smb.conf "encrypt passwords = no" (since the kernel client will only send plaintext if the server says that password encryption is not supported - ie only will use plaintext if it is forced too due to server not supporting encryption)
b) smb.conf "max protocols = LANMAN2" (since the client only does plaintext with old lanman dialect)

On client:
c) echo 0x30 > /proc/fs/cifs/SecurityFlags (to allow client to send plaintext)
d) mount with cifs (not with smb2, which uses ntlmssp which does not support plaintext)

With those steps I see the client sending a plaintext password to the server

Right, that should be a reasonable workaround iff you have control over the server. What's needed at this point is a way to force the client to use LANMAN/plaintext auth even when we don't get a legacy NEGOTIATE response.

So, what's probably needed is to patch select_sectype() to handle this situation properly. The _clearest_ way to do it from a UI standpoint would be to allow someone to specify sec=plain or something as a mount option and then handle that in the switch block for each negprot response type.

Alternately (or maybe in addition to that) you could have select_sectype() check for certain values of global_secflags and force LANMAN + plaintext auth.

Presumably you could specify sec=lanman on mount to force the client to negotiate lanman? So wouldn't this work without the smb.conf max protocols set if you specify "sec=lanman" ... or if we want to pass "sec=ntlm" (not ntlmssp) to force us to use non-NTLMSSP ie original nt style session setup request format, but to allow "sec=ntlm" to send plaintext we would need the equivalent line to this (which is in calc_lanman_hash) but in the ntlm hash generation

	if (!encrypt && global_secflags & CIFSSEC_MAY_PLNTXT) {
		memcpy(lnm_session_key, password_with_pad,
			CIFS_ENCPWD_SIZE);

the value of encrypt is set based on the server returning capabilities on negotiate that do not include encryption (ie setting smb.conf password encrypt = no)

My notes about this issue:

Change due to commit
3f618223dc0bdcbc8d510350e78ee2195ff93768

Before this patch was introduced, the security method used was set in the negotiation phase ie. set by the first mount of a share on the server. Subsequently new sessions on that server re-used the authentication information from the first session.

As a result of the patch, we now use the server->negflavor field to the flavour negotiated. The flavour is negotiated based on the data returned in the negotiate response and can be deduced simply by looking at the WordCount of the negotiate response.

http://msdn.microsoft.com/en-us/library/ee441946.aspx
--
If the server has selected any dialect from LAN Manager 1.0 through LAN Manager 2.1, WordCount MUST be 0x0D. See [XOPEN-SMB] for a specification of the LAN Manager dialects other than LAN Manager 2.1. [SMB-LM21] provides documentation on the extensions to the LAN Manager 2.0 dialect that define the LAN Manager 2.1 dialect.

If the server has selected the NT LAN Manager dialect, then WordCount MUST be 0x11.
--

Accordingly, we set the negotiate flavour in 

int
CIFSSMBNegotiate(const unsigned int xid, struct cifs_ses *ses)
{
..
//If word count is 13, the negotiate response suggests that the server supports LANMAN authentication flavour.
        } else if (pSMBr->hdr.WordCount == 13) {
                server->negflavor = CIFS_NEGFLAVOR_LANMAN;
..
//Else in case wordcount is set to 17. ie. NTLM dialect
        //Check the encryption key length set. This according to the doc
        //linked above, is set to 0 or 8.
        //First case is in case server supports challenge response authentication. 
        if (pSMBr->EncryptionKeyLength == CIFS_CRYPTO_KEY_SIZE) {
                server->negflavor = CIFS_NEGFLAVOR_UNENCAP;
                memcpy(ses->server->cryptkey, pSMBr->u.EncryptionKey,
                       CIFS_CRYPTO_KEY_SIZE);
        //Or check to see if extended security is enabled in which case we use 
        //Extended ie. encapsulated encryption.
        } else if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC ||
                        server->capabilities & CAP_EXTENDED_SECURITY) &&
                                (pSMBr->EncryptionKeyLength == 0)) {
                server->negflavor = CIFS_NEGFLAVOR_EXTENDED;
                rc = decode_ext_sec_blob(ses, pSMBr);
        //Check to see if the server supports password encryption.
        } else if (server->sec_mode & SECMODE_PW_ENCRYPT) {
                rc = -EIO; /* no crypt key only if plain text pwd */
        //default is to use unencapsulated NTLM/NTLMv2 authentication.
        } else {
                server->negflavor = CIFS_NEGFLAVOR_UNENCAP;
                server->capabilities &= ~CAP_EXTENDED_SECURITY;
        }
}

We get into trouble because we do not expect to do plain text password authentication when the Negotiate protocol select a NT Lan Manager dialect ie. CIFS_NEGFLAVOR_UNENCAP or CIFS_NEGFLAVOR_EXTENDED.

//We then set the authentication method based on the mount option passed for mounting this particular share.
int
CIFS_SessSetup(const unsigned int xid, struct cifs_ses *ses,
               const struct nls_table *nls_cp)
{
..
        type = select_sectype(ses->server, ses->sectype);
..
        if (type == Unspecified) {
                cifs_dbg(VFS,
                        "Unable to select appropriate authentication method!");
                return -EINVAL;
        }
..
}

enum securityEnum
select_sectype(struct TCP_Server_Info *server, enum securityEnum requested)
{
        switch (server->negflavor) {
        case CIFS_NEGFLAVOR_EXTENDED:
                switch (requested) {
                case Kerberos:
                case RawNTLMSSP:
                        return requested;
                case Unspecified:
                        if (server->sec_ntlmssp &&
                            (global_secflags & CIFSSEC_MAY_NTLMSSP))
                                return RawNTLMSSP;
                        if ((server->sec_kerberos || server->sec_mskerberos) &&
                            (global_secflags & CIFSSEC_MAY_KRB5))
                                return Kerberos;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        case CIFS_NEGFLAVOR_UNENCAP:
                switch (requested) {
                case NTLM:
                case NTLMv2:
                        return requested;
                case Unspecified:
                        if (global_secflags & CIFSSEC_MAY_NTLMV2)
                                return NTLMv2;
                        if (global_secflags & CIFSSEC_MAY_NTLM)
                                return NTLM;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        case CIFS_NEGFLAVOR_LANMAN:
                switch (requested) {
                case LANMAN:
                        return requested;
                case Unspecified:
                        if (global_secflags & CIFSSEC_MAY_LANMAN)
                                return LANMAN;
                        /* Fallthrough */
                default:
                        return Unspecified;
                }
        default:
                return Unspecified;
        }
}

In this particular case, the server sets a NT LanManager Dialect which sets the negflaour to CIFS_NEGFLAVOR_EXTENDED or to CIFS_NEGFLAVOR_UNENCAP(set depending on encryption key returned in the negotiate response) which prevents the user from using plain text authentication which requires LANMAN authentication.

http://thread.gmane.org/gmane.linux.kernel.cifs/8881

It is not clear to me. Was that fix included in a specific kernel version or it is still under evaluation?

The patch required to fix this issue has been included in the upstream kernel
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/cifs?id=dde2356c8466298bd77fa699e0ea296372eed47b

We now wait for the patches to be pulled into the Fedora kernel.

(In reply to Sachin Prabhu from comment #10)
> The patch required to fix this issue has been included in the upstream kernel
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/
> cifs?id=dde2356c8466298bd77fa699e0ea296372eed47b
> 
> We now wait for the patches to be pulled into the Fedora kernel.

Shouldn't that be CC'd to stable?  It's a regression in 3.11 and the patch is relatively small.  It's already in 3.12-rc6, so getting it into 3.11.7 should not be difficult.

Added to Fedora git.  Should likely still be pushed into upstream stable.

kernel-3.11.6-302.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.6-302.fc20

kernel-3.11.6-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.11.6-201.fc19

kernel-3.11.6-101.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.6-101.fc18

Package kernel-3.11.6-101.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.6-101.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20545/kernel-3.11.6-101.fc18
then log in and leave karma (feedback).

It works fine:

# yum versionlock clear
Loaded plugins: auto-update-debuginfo, fastestmirror, refresh-packagekit,
              : versionlock
versionlock cleared

# yum --enablerepo=updates-testing update kernel\*
...
================================================================================
 Package            Arch       Version                Repository           Size
================================================================================
Installing:
 kernel             x86_64     3.11.6-201.fc19        updates-testing      30 M
 kernel-devel       x86_64     3.11.6-201.fc19        updates-testing     8.4 M
Updating:
 kernel-headers     x86_64     3.11.6-201.fc19        updates-testing     883 k
...

$ uname -a
Linux bb229 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I've tested read/write operations on the share and no issue was observed. I've added +1 karma. Many thanks for the quick resolution!

kernel-3.11.7-300.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.11.7-300.fc20

kernel-3.11.7-100.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.11.7-100.fc18

kernel-3.11.6-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Package kernel-3.11.7-300.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.11.7-300.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20705/kernel-3.11.7-300.fc20
then log in and leave karma (feedback).

kernel-3.11.7-300.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

kernel-3.11.7-100.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.