Bug 1011621

Summary: Unable to mount plain text password Samba shares
Product: [Fedora] Fedora Reporter: Panos Kavalagios <Panos.Kavalagios>
Component: kernelAssignee: Sachin Prabhu <sprabhu>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 19CC: gansalmon, itamar, jlayton, jonathan, kernel-maint, madhu.chinakonda, marcelo.barbosa, smfrench, sprabhu, ssorce
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: kernel-3.11.7-100.fc18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-10 07:56:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Panos Kavalagios 2013-09-24 16:18:49 UTC
Description of problem: Mount is failing for a samba share.

Version-Release number of selected component (if applicable): cifs-utils-6.1-3.fc19.x86_64

How reproducible: Mount a plain text samba share with the following option:
echo '0x30' > /proc/fs/cifs/SecurityFlags

Steps to Reproduce:
1. Use mount command

Actual results: The mount fails with the following explaination:

mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

and dmesg output:

CIFS VFS: Unable to select appropriate authentication method!
CIFS VFS: Send error in SessSetup = -22
CIFS VFS: cifs_mount failed w/return code = -22

Expected results: The mount point should have been mounted as used in the past.

Additional info: The following options are used in rc.local:

# Load CIFS module
modprobe cifs
# Disable Unix extensions for link dereferencing at server side
echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled
# Set lower security for old samba versions
echo '0x30' > /proc/fs/cifs/SecurityFlags

Comment 1 Panos Kavalagios 2013-09-26 07:50:28 UTC
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.

Comment 2 Panos Kavalagios 2013-09-26 11:34:35 UTC
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

Comment 3 Jeff Layton 2013-09-26 14:32:00 UTC
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.

Comment 4 Steven French 2013-09-26 21:36:47 UTC
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

Comment 5 Jeff Layton 2013-09-26 21:58:34 UTC
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.

Comment 6 Steven French 2013-09-26 22:07:09 UTC
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,

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)

Comment 7 Sachin Prabhu 2013-09-27 08:54:04 UTC
My notes about this issue:

Change due to commit

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.

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 

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,
        //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.
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) {
                        "Unable to select appropriate authentication method!");
                return -EINVAL;

enum securityEnum
select_sectype(struct TCP_Server_Info *server, enum securityEnum requested)
        switch (server->negflavor) {
                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 */
                        return Unspecified;
                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 */
                        return Unspecified;
                switch (requested) {
                case LANMAN:
                        return requested;
                case Unspecified:
                        if (global_secflags & CIFSSEC_MAY_LANMAN)
                                return LANMAN;
                        /* Fallthrough */
                        return Unspecified;
                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.

Comment 8 Sachin Prabhu 2013-09-27 17:41:18 UTC

Comment 9 Panos Kavalagios 2013-10-29 09:23:37 UTC
It is not clear to me. Was that fix included in a specific kernel version or it is still under evaluation?

Comment 10 Sachin Prabhu 2013-10-29 10:23:06 UTC
The patch required to fix this issue has been included in the upstream kernel

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

Comment 11 Josh Boyer 2013-10-29 17:43:27 UTC
(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.

Comment 12 Josh Boyer 2013-10-29 18:24:24 UTC
Added to Fedora git.  Should likely still be pushed into upstream stable.

Comment 13 Fedora Update System 2013-11-02 19:15:14 UTC
kernel-3.11.6-302.fc20 has been submitted as an update for Fedora 20.

Comment 14 Fedora Update System 2013-11-02 19:20:33 UTC
kernel-3.11.6-201.fc19 has been submitted as an update for Fedora 19.

Comment 15 Fedora Update System 2013-11-02 19:24:06 UTC
kernel-3.11.6-101.fc18 has been submitted as an update for Fedora 18.

Comment 16 Fedora Update System 2013-11-03 04:35:04 UTC
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:
then log in and leave karma (feedback).

Comment 17 Panos Kavalagios 2013-11-04 08:21:15 UTC
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
 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
 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!

Comment 18 Fedora Update System 2013-11-04 20:17:40 UTC
kernel-3.11.7-300.fc20 has been submitted as an update for Fedora 20.

Comment 19 Fedora Update System 2013-11-04 20:19:48 UTC
kernel-3.11.7-100.fc18 has been submitted as an update for Fedora 18.

Comment 20 Fedora Update System 2013-11-05 02:58:00 UTC
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.

Comment 21 Fedora Update System 2013-11-05 20:04:20 UTC
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:
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2013-11-10 07:56:16 UTC
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.

Comment 23 Fedora Update System 2013-11-13 02:14:31 UTC
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.