1. 27 6月, 2013 1 次提交
    • S
      SMB2 FSCTL and IOCTL worker function · 4a72dafa
      Steve French 提交于
      This worker function is needed to send SMB2 fsctl
      (and ioctl) requests including:
      
      validating negotiation info (secure negotiate)
      querying the servers network interfaces
      copy offload (refcopy)
      
      Followon patches for the above three will use this.
      This patch also does general validation of the response.
      
      In the future, as David Disseldorp notes, for the copychunk ioctl
      case, we will want to enhance the response processing to allow
      returning the chunk request limits to the caller (even
      though the server returns an error, in that case we would
      return data that the caller could use - see 2.2.32.1).
      
      See MS-SMB2 Section 2.2.31 for more details on format of fsctl.
      Acked-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      4a72dafa
  2. 10 12月, 2012 1 次提交
  3. 25 9月, 2012 21 次提交
  4. 28 7月, 2012 2 次提交
  5. 25 7月, 2012 8 次提交
  6. 24 7月, 2012 2 次提交
  7. 06 8月, 2010 1 次提交
    • W
      DNS: Separate out CIFS DNS Resolver code · 1a4240f4
      Wang Lei 提交于
      Separate out the DNS resolver key type from the CIFS filesystem into its own
      module so that it can be made available for general use, including the AFS
      filesystem module.
      
      This facility makes it possible for the kernel to upcall to userspace to have
      it issue DNS requests, package up the replies and present them to the kernel
      in a useful form.  The kernel is then able to cache the DNS replies as keys
      can be retained in keyrings.
      
      Resolver keys are of type "dns_resolver" and have a case-insensitive
      description that is of the form "[<type>:]<domain_name>".  The optional <type>
      indicates the particular DNS lookup and packaging that's required.  The
      <domain_name> is the query to be made.
      
      If <type> isn't given, a basic hostname to IP address lookup is made, and the
      result is stored in the key in the form of a printable string consisting of a
      comma-separated list of IPv4 and IPv6 addresses.
      
      This key type is supported by userspace helpers driven from /sbin/request-key
      and configured through /etc/request-key.conf.  The cifs.upcall utility is
      invoked for UNC path server name to IP address resolution.
      
      The CIFS functionality is encapsulated by the dns_resolve_unc_to_ip() function,
      which is used to resolve a UNC path to an IP address for CIFS filesystem.  This
      part remains in the CIFS module for now.
      
      See the added Documentation/networking/dns_resolver.txt for more information.
      Signed-off-by: NWang Lei <wang840925@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      1a4240f4
  8. 31 7月, 2010 1 次提交
  9. 23 7月, 2010 1 次提交
    • D
      CIFS: Fix a malicious redirect problem in the DNS lookup code · 4c0c03ca
      David Howells 提交于
      Fix the security problem in the CIFS filesystem DNS lookup code in which a
      malicious redirect could be installed by a random user by simply adding a
      result record into one of their keyrings with add_key() and then invoking a
      CIFS CFS lookup [CVE-2010-2524].
      
      This is done by creating an internal keyring specifically for the caching of
      DNS lookups.  To enforce the use of this keyring, the module init routine
      creates a set of override credentials with the keyring installed as the thread
      keyring and instructs request_key() to only install lookup result keys in that
      keyring.
      
      The override is then applied around the call to request_key().
      
      This has some additional benefits when a kernel service uses this module to
      request a key:
      
       (1) The result keys are owned by root, not the user that caused the lookup.
      
       (2) The result keys don't pop up in the user's keyrings.
      
       (3) The result keys don't come out of the quota of the user that caused the
           lookup.
      
      The keyring can be viewed as root by doing cat /proc/keys:
      
      2a0ca6c3 I-----     1 perm 1f030000     0     0 keyring   .dns_resolver: 1/4
      
      It can then be listed with 'keyctl list' by root.
      
      	# keyctl list 0x2a0ca6c3
      	1 key in keyring:
      	726766307: --alswrv     0     0 dns_resolver: foo.bar.com
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-and-Tested-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NSteve French <smfrench@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4c0c03ca
  10. 08 2月, 2008 1 次提交
  11. 11 1月, 2008 1 次提交