From patchwork Sun Jun 22 17:40:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shirish Pargaonkar X-Patchwork-Id: 4396241 Return-Path: X-Original-To: patchwork-cifs-client@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 03E0B9F1D6 for ; Sun, 22 Jun 2014 17:40:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E0EE12020E for ; Sun, 22 Jun 2014 17:40:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 032482020A for ; Sun, 22 Jun 2014 17:40:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbaFVRk1 (ORCPT ); Sun, 22 Jun 2014 13:40:27 -0400 Received: from mail-oa0-f48.google.com ([209.85.219.48]:49780 "EHLO mail-oa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751451AbaFVRk0 (ORCPT ); Sun, 22 Jun 2014 13:40:26 -0400 Received: by mail-oa0-f48.google.com with SMTP id m1so9251151oag.7 for ; Sun, 22 Jun 2014 10:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=JfAzoxU61JHRAAw4UNgGoz/quab3qVcEpgl/hPR3Xno=; b=IKk2g4tzu/mVQeFQD3oj3R3/BvNLxtfE/5gIlmuR3ZQ7uzoMI1JNDP07Hwea19ATpw ZHrrAwOf/A8soo2RUPuzIpfeMUEiG5kGy+vLsoe55nL4b2h3wU+DUNKhHT0hY+SbJJcF SOHPIiJyuSB7gzLShKFLy6d0c2xJl8dSx5eGGitMgrvQJPoD6bRIkRD5XTrOeq6ubI9C xWhUHZPSH+EKgdZl9GagFraxYoKo8jyyUGWd2ORCVgC/jWu9VDxqqd0gFpkZxmlOEUAI p5sTiVHXCWGu5LBFQolEuEb4EV7uNq3nnsMbdcChZUfM7nLdACNEP5Ra/9n9Jkm0TAVD qP/w== X-Received: by 10.60.141.67 with SMTP id rm3mr2631824oeb.78.1403458825836; Sun, 22 Jun 2014 10:40:25 -0700 (PDT) Received: from shirish-ThinkPad-T400.gns.novell.com (75-13-85-90.lightspeed.austtx.sbcglobal.net. [75.13.85.90]) by mx.google.com with ESMTPSA id c4sm12542860oeu.0.2014.06.22.10.40.23 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Jun 2014 10:40:24 -0700 (PDT) From: shirishpargaonkar@gmail.com X-Google-Original-From: spargaonkar@suse.com To: smfrench@gmail.com Cc: linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, Shirish Pargaonkar Subject: [PATCH] cifs: Workaround a probable Samba case sensitivity bug Date: Sun, 22 Jun 2014 12:40:16 -0500 Message-Id: <1403458816-10036-1-git-send-email-spargaonkar@suse.com> X-Mailer: git-send-email 1.8.3.2 Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Shirish Pargaonkar When a client supports extended security but server does not, and that client, in Flags2 field of smb header indicates that - it supports extended security negotiation - it does not support security signatures - it does not require security signatures Samba server treats a client as a Vista client. That turns off case sensitivity and that is a problem for cifs vfs client. This is the Samba server code. I am not sure what is the reasoning behind this. ------------- source3/smbd/negprot.c reply_nt1() ------------------ /* Check the flags field to see if this is Vista. WinXP sets it and Vista does not. But we have to distinguish from NT which doesn't set it either. */ if ( (req->flags2 & FLAGS2_EXTENDED_SECURITY) && ((req->flags2 & FLAGS2_SMB_SECURITY_SIGNATURES_REQUIRED) == 0) ) { if (get_remote_arch() != RA_SAMBA) { set_remote_arch( RA_VISTA ); } } -------------------------------------------------------------------- But if this code has to stay, perhaps this line if (get_remote_arch() != RA_SAMBA) { could be changed to if ((get_remote_arch() != RA_SAMBA) && (get_remote_arch() != RA_CIFSFS)) { (I tested with this code change and it works) I do not know what could be a correct fix for this is in cifs client code. I think it is perfectly alright for cifs client to set these three flag2 bits (extended security, security signature, and security signature required). the way it sets in smb header and still retain its identity as cifsfs. cifs client could set Security Signature bit in Flags2 in negotiate request since it does support signatures but does not have to require security signatures unless client asks using sec= mount option. For subsequent packets, cifs client decides whether to set Security Signature bit in Flags2 or not based on server (server->sign). So I have attached a patch with that change. The way I recreated it was using these three options in smb.conf client NTLMv2 auth = yes client use spnego = no use spnego = no Signed-by: Shirish Pargaonkar --- fs/cifs/cifssmb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index 6ce4e09..2d7d131 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -568,6 +568,8 @@ CIFSSMBNegotiate(const unsigned int xid, struct cifs_ses *ses) pSMB->hdr.Mid = get_next_mid(server); pSMB->hdr.Flags2 |= (SMBFLG2_UNICODE | SMBFLG2_ERR_STATUS); + pSMB->hdr.Flags2 |= (SMBFLG2_SECURITY_SIGNATURE | + SMBFLG2_SECURITY_SIGNATURE_REQUIRED); if (should_set_ext_sec_flag(ses->sectype)) { cifs_dbg(FYI, "Requesting extended security.");