1. 18 9月, 2013 1 次提交
    • J
      cifs: stop trying to use virtual circuits · 9ae6cf60
      Jeff Layton 提交于
      Currently, we try to ensure that we use vcnum of 0 on the first
      established session on a connection and then try to use a different
      vcnum on each session after that.
      
      This is a little odd, since there's no real reason to use a different
      vcnum for each SMB session. I can only assume there was some confusion
      between SMB sessions and VCs. That's somewhat understandable since they
      both get created during SESSION_SETUP, but the documentation indicates
      that they are really orthogonal. The comment on max_vcs in particular
      looks quite misguided. An SMB session is already uniquely identified
      by the SMB UID value -- there's no need to again uniquely ID with a
      VC.
      
      Furthermore, a vcnum of 0 is a cue to the server that it should release
      any resources that were previously held by the client. This sounds like
      a good thing, until you consider that:
      
      a) it totally ignores the fact that other programs on the box (e.g.
      smbclient) might have connections established to the server. Using a
      vcnum of 0 causes them to get kicked off.
      
      b) it causes problems with NAT. If several clients are connected to the
      same server via the same NAT'ed address, whenever one connects to the
      server it kicks off all the others, which then reconnect and kick off
      the first one...ad nauseum.
      
      I don't see any reason to ignore the advice in "Implementing CIFS" which
      has a comprehensive treatment of virtual circuits. In there, it states
      "...and contrary to the specs the client should always use a VcNumber of
      one, never zero."
      
      Have the client just use a hardcoded vcnum of 1, and stop abusing the
      special behavior of vcnum 0.
      Reported-by: NSauron99@gmx.de <sauron99@gmx.de>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NVolker Lendecke <vl@samba.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      9ae6cf60
  2. 10 9月, 2013 4 次提交
  3. 09 9月, 2013 6 次提交
  4. 31 7月, 2013 2 次提交
  5. 11 7月, 2013 2 次提交
  6. 28 6月, 2013 1 次提交
  7. 27 6月, 2013 2 次提交
    • S
      [CIFS] Fix build warning · e65a5cb4
      Steve French 提交于
      Fix build warning in Shirish's recent SMB3 signing patch
      which occurs when SMB2 support is disabled in Kconfig.
      
      fs/built-in.o: In function `cifs_setup_session':
      >> (.text+0xa1767): undefined reference to `generate_smb3signingkey'
      
      Pointed out by: automated 0-DAY kernel build testing backend
      Intel Open Source Technology Center
      
      CC: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      e65a5cb4
    • S
      [CIFS] SMB3 Signing enablement · 429b46f4
      Steve French 提交于
      SMB3 uses a much faster method of signing (which is also better in other ways),
      AES-CMAC.  With the kernel now supporting AES-CMAC since last release, we
      are overdue to allow SMB3 signing (today only CIFS and SMB2 and SMB2.1,
      but not SMB3 and SMB3.1 can sign) - and we need this also for checking
      secure negotation and also per-share encryption (two other new SMB3 features
      which we need to implement).
      
      This patch needs some work in a few areas - for example we need to
      move signing for SMB2/SMB3 from per-socket to per-user (we may be able to
      use the "nosharesock" mount option in the interim for the multiuser case),
      and Shirish found a bug in the earlier authentication overhaul
      (setting signing flags properly) - but those can be done in followon
      patches.
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      429b46f4
  8. 24 6月, 2013 12 次提交
  9. 13 2月, 2013 5 次提交
  10. 02 1月, 2013 2 次提交
  11. 12 12月, 2012 1 次提交
  12. 10 12月, 2012 1 次提交
  13. 06 12月, 2012 1 次提交