1. 02 7月, 2013 1 次提交
  2. 26 4月, 2013 1 次提交
  3. 30 3月, 2013 6 次提交
    • C
      SUNRPC: Remove EXPORT_SYMBOL_GPL() from GSS mech switch · 5007220b
      Chuck Lever 提交于
      Clean up: Reduce the symbol table footprint for auth_rpcgss.ko by
      removing exported symbols for functions that are no longer used
      outside of auth_rpcgss.ko.
      
      The remaining two EXPORTs in gss_mech_switch.c get documenting
      comments.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      5007220b
    • C
      SUNRPC: Make gss_mech_get() static · 6599c0ac
      Chuck Lever 提交于
      gss_mech_get() is no longer used outside of gss_mech_switch.c.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6599c0ac
    • C
      SUNRPC: Refactor nfsd4_do_encode_secinfo() · a77c806f
      Chuck Lever 提交于
      Clean up.  This matches a similar API for the client side, and
      keeps ULP fingers out the of the GSS mech switch.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Acked-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a77c806f
    • C
      SUNRPC: Consider qop when looking up pseudoflavors · 83523d08
      Chuck Lever 提交于
      The NFSv4 SECINFO operation returns a list of security flavors that
      the server supports for a particular share.  An NFSv4 client is
      supposed to pick a pseudoflavor it supports that corresponds to one
      of the flavors returned by the server.
      
      GSS flavors in this list have a GSS tuple that identify a specific
      GSS pseudoflavor.
      
      Currently our client ignores the GSS tuple's "qop" value.  A
      matching pseudoflavor is chosen based only on the OID and service
      value.
      
      So far this omission has not had much effect on Linux.  The NFSv4
      protocol currently supports only one qop value: GSS_C_QOP_DEFAULT,
      also known as zero.
      
      However, if an NFSv4 server happens to return something other than
      zero in the qop field, our client won't notice.  This could cause
      the client to behave in incorrect ways that could have security
      implications.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      83523d08
    • C
      SUNRPC: Load GSS kernel module by OID · f783288f
      Chuck Lever 提交于
      The current GSS mech switch can find and load GSS pseudoflavor
      modules by name ("krb5") or pseudoflavor number ("390003"), but
      cannot find GSS modules by GSS tuple:
      
        [ "1.2.840.113554.1.2.2", GSS_C_QOP_DEFAULT, RPC_GSS_SVC_NONE ]
      
      This is important when dealing with a SECINFO request.  A SECINFO
      reply contains a list of flavors the server supports for the
      requested export, but GSS flavors also have a GSS tuple that maps
      to a pseudoflavor (like 390003 for krb5).
      
      If the GSS module that supports the OID in the tuple is not loaded,
      our client is not able to load that module dynamically to support
      that pseudoflavor.
      
      Add a way for the GSS mech switch to load GSS pseudoflavor support
      by OID before searching for the pseudoflavor that matches the OID
      and service.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f783288f
    • C
      SUNRPC: Introduce rpcauth_get_pseudoflavor() · 9568c5e9
      Chuck Lever 提交于
      A SECINFO reply may contain flavors whose kernel module is not
      yet loaded by the client's kernel.  A new RPC client API, called
      rpcauth_get_pseudoflavor(), is introduced to do proper checking
      for support of a security flavor.
      
      When this API is invoked, the RPC client now tries to load the
      module for each flavor first before performing the "is this
      supported?" check.  This means if a module is available on the
      client, but has not been loaded yet, it will be loaded and
      registered automatically when the SECINFO reply is processed.
      
      The new API can take a full GSS tuple (OID, QoP, and service).
      Previously only the OID and service were considered.
      
      nfs_find_best_sec() is updated to verify all flavors requested in a
      SECINFO reply, including AUTH_NULL and AUTH_UNIX.  Previously these
      two flavors were simply assumed to be supported without consulting
      the RPC client.
      
      Note that the replaced version of nfs_find_best_sec() can return
      RPC_AUTH_MAXFLAVOR if the server returns a recognized OID but an
      unsupported "service" value.  nfs_find_best_sec() now returns
      RPC_AUTH_UNIX in this case.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      9568c5e9
  4. 01 2月, 2013 1 次提交
  5. 18 7月, 2012 1 次提交
  6. 17 7月, 2012 1 次提交
    • C
      SUNRPC: Add rpcauth_list_flavors() · 6a1a1e34
      Chuck Lever 提交于
      The gss_mech_list_pseudoflavors() function provides a list of
      currently registered GSS pseudoflavors.  This list does not include
      any non-GSS flavors that have been registered with the RPC client.
      nfs4_find_root_sec() currently adds these extra flavors by hand.
      
      Instead, nfs4_find_root_sec() should be looking at the set of flavors
      that have been explicitly registered via rpcauth_register().  And,
      other areas of code will soon need the same kind of list that
      contains all flavors the kernel currently knows about (see below).
      
      Rather than cloning the open-coded logic in nfs4_find_root_sec() to
      those new places, introduce a generic RPC function that generates a
      full list of registered auth flavors and pseudoflavors.
      
      A new rpc_authops method is added that lists a flavor's
      pseudoflavors, if it has any.  I encountered an interesting module
      loader loop when I tried to get the RPC client to invoke
      gss_mech_list_pseudoflavors() by name.
      
      This patch is a pre-requisite for server trunking discovery, and a
      pre-requisite for fixing up the in-kernel mount client to do better
      automatic security flavor selection.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      6a1a1e34
  7. 04 5月, 2012 1 次提交
  8. 16 7月, 2011 1 次提交
  9. 25 3月, 2011 2 次提交
  10. 24 9月, 2010 1 次提交
  11. 15 5月, 2010 2 次提交
  12. 19 12月, 2009 1 次提交
  13. 24 12月, 2008 1 次提交
  14. 18 3月, 2008 1 次提交
  15. 18 7月, 2007 1 次提交
  16. 11 2月, 2007 1 次提交
  17. 04 2月, 2007 1 次提交
  18. 22 7月, 2006 1 次提交
  19. 01 7月, 2006 1 次提交
  20. 09 11月, 2005 1 次提交
  21. 19 10月, 2005 2 次提交
  22. 24 9月, 2005 1 次提交
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4