1. 27 5月, 2011 3 次提交
  2. 26 5月, 2011 1 次提交
  3. 24 5月, 2011 1 次提交
  4. 23 5月, 2011 3 次提交
  5. 19 5月, 2011 8 次提交
  6. 28 1月, 2011 1 次提交
  7. 26 1月, 2011 1 次提交
  8. 21 1月, 2011 2 次提交
  9. 20 1月, 2011 1 次提交
    • P
      CIFS: Fix oplock break handling (try #2) · 12fed00d
      Pavel Shilovsky 提交于
      When we get oplock break notification we should set the appropriate
      value of OplockLevel field in oplock break acknowledge according to
      the oplock level held by the client in this time. As we only can have
      level II oplock or no oplock in the case of oplock break, we should be
      aware only about clientCanCacheRead field in cifsInodeInfo structure.
      
      Also fix bug connected with wrong interpretation of OplockLevel field
      during oplock break notification processing.
      Signed-off-by: NPavel Shilovsky <piastryyy@gmail.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      12fed00d
  10. 08 12月, 2010 1 次提交
  11. 07 12月, 2010 1 次提交
  12. 30 11月, 2010 2 次提交
  13. 11 11月, 2010 1 次提交
  14. 06 11月, 2010 1 次提交
  15. 03 11月, 2010 1 次提交
  16. 27 10月, 2010 3 次提交
    • S
      NTLM auth and sign - Use kernel crypto apis to calculate hashes and smb signatures · 307fbd31
      Shirish Pargaonkar 提交于
      Use kernel crypto sync hash apis insetead of cifs crypto functions.
      The calls typically corrospond one to one except that insead of
      key init, setkey is used.
      
      Use crypto apis to generate smb signagtures also.
      Use hmac-md5 to genereate ntlmv2 hash, ntlmv2 response, and HMAC (CR1 of
      ntlmv2 auth blob.
      User crypto apis to genereate signature and to verify signature.
      md5 hash is used to calculate signature.
      Use secondary key to calculate signature in case of ntlmssp.
      
      For ntlmv2 within ntlmssp, during signature calculation, only 16 bytes key
      (a nonce) stored within session key is used. during smb signature calculation.
      For ntlm and ntlmv2 without extended security, 16 bytes key
      as well as entire response (24 bytes in case of ntlm and variable length
      in case of ntlmv2) is used for smb signature calculation.
      For kerberos, there is no distinction between key and response.
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      307fbd31
    • S
      NTLM auth and sign - Define crypto hash functions and create and send keys needed for key exchange · d2b91521
      Shirish Pargaonkar 提交于
      Mark dependency on crypto modules in Kconfig.
      
      Defining per structures sdesc and cifs_secmech which are used to store
      crypto hash functions and contexts.  They are stored per smb connection
      and used for all auth mechs to genereate hash values and signatures.
      
      Allocate crypto hashing functions, security descriptiors, and respective
      contexts when a smb/tcp connection is established.
      Release them when a tcp/smb connection is taken down.
      
      md5 and hmac-md5 are two crypto hashing functions that are used
      throught the life of an smb/tcp connection by various functions that
      calcualte signagure and ntlmv2 hash, HMAC etc.
      
      structure ntlmssp_auth is defined as per smb connection.
      
      ntlmssp_auth holds ciphertext which is genereated by rc4/arc4 encryption of
      secondary key, a nonce using ntlmv2 session key and sent in the session key
      field of the type 3 message sent by the client during ntlmssp
      negotiation/exchange
      
      A key is exchanged with the server if client indicates so in flags in
      type 1 messsage and server agrees in flag in type 2 message of ntlmssp
      negotiation.  If both client and agree, a key sent by client in
      type 3 message of ntlmssp negotiation in the session key field.
      The key is a ciphertext generated off of secondary key, a nonce, using
      ntlmv2 hash via rc4/arc4.
      
      Signing works for ntlmssp in this patch. The sequence number within
      the server structure needs to be zero until session is established
      i.e. till type 3 packet of ntlmssp exchange of a to be very first
      smb session on that smb connection is sent.
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d2b91521
    • S
      NTLM auth and sign - Allocate session key/client response dynamically · 21e73393
      Shirish Pargaonkar 提交于
      Start calculating auth response within a session.  Move/Add pertinet
      data structures like session key, server challenge and ntlmv2_hash in
      a session structure.  We should do the calculations within a session
      before copying session key and response over to server data
      structures because a session setup can fail.
      
      Only after a very first smb session succeeds, it copy/make its
      session key, session key of smb connection.  This key stays with
      the smb connection throughout its life.
      sequence_number within server is set to 0x2.
      
      The authentication Message Authentication Key (mak) which consists
      of session key followed by client response within structure session_key
      is now dynamic.  Every authentication type allocates the key + response
      sized memory within its session structure and later either assigns or
      frees it once the client response is sent and if session's session key
      becomes connetion's session key.
      
      ntlm/ntlmi authentication functions are rearranged.  A function
      named setup_ntlm_resp(), similar to setup_ntlmv2_resp(), replaces
      function cifs_calculate_session_key().
      
      size of CIFS_SESS_KEY_SIZE is changed to 16, to reflect the byte size
      of the key it holds.
      Reviewed-by: NJeff Layton <jlayton@samba.org>
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      21e73393
  17. 18 10月, 2010 4 次提交
  18. 13 10月, 2010 1 次提交
    • J
      cifs: don't use vfsmount to pin superblock for oplock breaks · d7c86ff8
      Jeff Layton 提交于
      Filesystems aren't really supposed to do anything with a vfsmount. It's
      considered a layering violation since vfsmounts are entirely managed at
      the VFS layer.
      
      CIFS currently keeps an active reference to a vfsmount in order to
      prevent the superblock vanishing before an oplock break has completed.
      What we really want to do instead is to keep sb->s_active high until the
      oplock break has completed. This patch borrows the scheme that NFS uses
      for handling sillyrenames.
      
      An atomic_t is added to the cifs_sb_info. When it transitions from 0 to
      1, an extra reference to the superblock is taken (by bumping the
      s_active value). When it transitions from 1 to 0, that reference is
      dropped and a the superblock teardown may proceed if there are no more
      references to it.
      
      Also, the vfsmount pointer is removed from cifsFileInfo and from
      cifs_new_fileinfo, and some bogus forward declarations are removed from
      cifsfs.h.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NSuresh Jayaraman <sjayaraman@suse.de>
      Acked-by: NDave Kleikamp <shaggy@linux.vnet.ibm.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      d7c86ff8
  19. 07 10月, 2010 2 次提交
  20. 30 9月, 2010 2 次提交