1. 22 Apr, 2013 1 commit
    • Chuck Lever's avatar
      NFS: Retry SETCLIENTID with AUTH_SYS instead of AUTH_NONE · 79d852bf
      Chuck Lever authored
      Recently I changed the SETCLIENTID code to use AUTH_GSS(krb5i), and
      then retry with AUTH_NONE if that didn't work.  This was to enable
      Kerberos NFS mounts to work without forcing Linux NFS clients to
      have a keytab on hand.
      
      Rick Macklem reports that the FreeBSD server accepts AUTH_NONE only
      for NULL operations (thus certainly not for SETCLIENTID).  Falling
      back to AUTH_NONE means our proposed 3.10 NFS client will not
      interoperate with FreeBSD servers over NFSv4 unless Kerberos is
      fully configured on both ends.
      
      If the Linux client falls back to using AUTH_SYS instead for
      SETCLIENTID, all should work fine as long as the NFS server is
      configured to allow AUTH_SYS for SETCLIENTID.
      
      This may still prevent access to Kerberos-only FreeBSD servers by
      Linux clients with no keytab.  Rick is of the opinion that the
      security settings the server applies to its pseudo-fs should also
      apply to the SETCLIENTID operation.
      
      Linux and Solaris NFS servers do not place that limitation on
      SETCLIENTID.  The security settings for the server's pseudo-fs are
      determined automatically as the union of security flavors allowed on
      real exports, as recommended by RFC 3530bis; and the flavors allowed
      for SETCLIENTID are all flavors supported by the respective server
      implementation.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      79d852bf
  2. 05 Apr, 2013 2 commits
  3. 04 Apr, 2013 3 commits
    • Trond Myklebust's avatar
      NFSv4: Fix the fallback to AUTH_NULL if krb5i is not available · 23631227
      Trond Myklebust authored
      If the rpcsec_gss_krb5 module cannot be loaded, the attempt to create
      an rpc_client in nfs4_init_client will currently fail with an EINVAL.
      Fix is to retry with AUTH_NULL.
      
      Regression introduced by the commit "NFS: Use "krb5i" to establish NFSv4
      state whenever possible"
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Chuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      23631227
    • Chuck Lever's avatar
      NFS: Use server-recommended security flavor by default (NFSv3) · 4580a92d
      Chuck Lever authored
      Since commit ec88f28d in 2009, checking if the user-specified flavor
      is in the server's flavor list has been the source of a few
      noticeable regressions (now fixed), but there is one that is still
      vexing.
      
      An NFS server can list AUTH_NULL in its flavor list, which suggests
      a client should try to mount the server with the flavor of the
      client's choice, but the server will squash all accesses.  In some
      cases, our client fails to mount a server because of this check,
      when the mount could have proceeded successfully.
      
      Skip this check if the user has specified "sec=" on the mount
      command line.  But do consult the server-provided flavor list to
      choose a security flavor if no sec= option is specified on the mount
      command.
      
      If a server lists Kerberos pseudoflavors before "sys" in its export
      options, our client now chooses Kerberos over AUTH_UNIX for mount
      points, when no security flavor is specified by the mount command.
      This could be surprising to some administrators or users, who would
      then need to have Kerberos credentials to access the export.
      
      Or, a client administrator may not have enabled rpc.gssd.  In this
      case, auth_rpcgss.ko might still be loadable, which is enough for
      the new logic to choose Kerberos over AUTH_UNIX.  But the mount
      would fail since no GSS context can be created without rpc.gssd
      running.
      
      To retain the use of AUTH_UNIX by default:
      
        o  The server administrator can ensure that "sys" is listed before
           Kerberos flavors in its export security options (see
           exports(5)),
      
        o  The client administrator can explicitly specify "sec=sys" on
           its mount command line (see nfs(5)),
      
        o  The client administrator can use "Sec=sys" in an appropriate
           section of /etc/nfsmount.conf (see nfsmount.conf(5)), or
      
        o  The client administrator can blacklist auth_rpcgss.ko.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4580a92d
    • Chuck Lever's avatar
      SUNRPC: Don't recognize RPC_AUTH_MAXFLAVOR · 1c74a244
      Chuck Lever authored
      RPC_AUTH_MAXFLAVOR is an invalid flavor, on purpose.  Don't allow
      any processing whatsoever if a caller passes it to rpcauth_create()
      or rpcauth_get_gssinfo().
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      1c74a244
  4. 29 Mar, 2013 15 commits
    • Chuck Lever's avatar
      NFS: Use "krb5i" to establish NFSv4 state whenever possible · 4edaa308
      Chuck Lever authored
      Currently our client uses AUTH_UNIX for state management on Kerberos
      NFS mounts in some cases.  For example, if the first mount of a
      server specifies "sec=sys," the SETCLIENTID operation is performed
      with AUTH_UNIX.  Subsequent mounts using stronger security flavors
      can not change the flavor used for lease establishment.  This might
      be less security than an administrator was expecting.
      
      Dave Noveck's migration issues draft recommends the use of an
      integrity-protecting security flavor for the SETCLIENTID operation.
      Let's ignore the mount's sec= setting and use krb5i as the default
      security flavor for SETCLIENTID.
      
      If our client can't establish a GSS context (eg. because it doesn't
      have a keytab or the server doesn't support Kerberos) we fall back
      to using AUTH_NULL.  For an operation that requires a
      machine credential (which never represents a particular user)
      AUTH_NULL is as secure as AUTH_UNIX.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      4edaa308
    • Chuck Lever's avatar
      NFS: Try AUTH_UNIX when PUTROOTFH gets NFS4ERR_WRONGSEC · c4eafe11
      Chuck Lever authored
      Most NFSv4 servers implement AUTH_UNIX, and administrators will
      prefer this over AUTH_NULL.  It is harmless for our client to try
      this flavor in addition to the flavors mandated by RFC 3530/5661.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      c4eafe11
    • Chuck Lever's avatar
      NFS: Use static list of security flavors during root FH lookup recovery · 9a744ba3
      Chuck Lever authored
      If the Linux NFS client receives an NFS4ERR_WRONGSEC error while
      trying to look up an NFS server's root file handle, it retries the
      lookup operation with various security flavors to see what flavor
      the NFS server will accept for pseudo-fs access.
      
      The list of flavors the client uses during retry consists only of
      flavors that are currently registered in the kernel RPC client.
      This list may not include any GSS pseudoflavors if auth_rpcgss.ko
      has not yet been loaded.
      
      Let's instead use a static list of security flavors that the NFS
      standard requires the server to implement (RFC 3530bis, section
      3.2.1).  The RPC client should now be able to load support for
      these dynamically; if not, they are skipped.
      
      Recovery behavior here is prescribed by RFC 3530bis, section
      15.33.5:
      
      > For LOOKUPP, PUTROOTFH and PUTPUBFH, the client will be unable to
      > use the SECINFO operation since SECINFO requires a current
      > filehandle and none exist for these two [sic] operations.  Therefore,
      > the client must iterate through the security triples available at
      > the client and reattempt the PUTROOTFH or PUTPUBFH operation.  In
      > the unfortunate event none of the MANDATORY security triples are
      > supported by the client and server, the client SHOULD try using
      > others that support integrity.  Failing that, the client can try
      > using AUTH_NONE, but because such forms lack integrity checks,
      > this puts the client at risk.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      9a744ba3
    • Chuck Lever's avatar
      NFS: Avoid PUTROOTFH when managing leases · 83ca7f5a
      Chuck Lever authored
      Currently, the compound operation the Linux NFS client sends to the
      server to confirm a client ID looks like this:
      
      	{ SETCLIENTID_CONFIRM; PUTROOTFH; GETATTR(lease_time) }
      
      Once the lease is confirmed, it makes sense to know how long before
      the client will have to renew it.  And, performing these operations
      in the same compound saves a round trip.
      
      Unfortunately, this arrangement assumes that the security flavor
      used for establishing a client ID can also be used to access the
      server's pseudo-fs.
      
      If the server requires a different security flavor to access its
      pseudo-fs than it allowed for the client's SETCLIENTID operation,
      the PUTROOTFH in this compound fails with NFS4ERR_WRONGSEC.  Even
      though the SETCLIENTID_CONFIRM succeeded, our client's trunking
      detection logic interprets the failure of the compound as a failure
      by the server to confirm the client ID.
      
      As part of server trunking detection, the client then begins another
      SETCLIENTID pass with the same nfs4_client_id.  This fails with
      NFS4ERR_CLID_INUSE because the first SETCLIENTID/SETCLIENTID_CONFIRM
      already succeeded in confirming that client ID -- it was the
      PUTROOTFH operation that caused the SETCLIENTID_CONFIRM compound to
      fail.
      
      To address this issue, separate the "establish client ID" step from
      the "accessing the server's pseudo-fs root" step.  The first access
      of the server's pseudo-fs may require retrying the PUTROOTFH
      operation with different security flavors.  This access is done in
      nfs4_proc_get_rootfh().
      
      That leaves the matter of how to retrieve the server's lease time.
      nfs4_proc_fsinfo() already retrieves the lease time value, though
      none of its callers do anything with the retrieved value (nor do
      they mark the lease as "renewed").
      
      Note that NFSv4.1 state recovery invokes nfs4_proc_get_lease_time()
      using the lease management security flavor.  This may cause some
      heartburn if that security flavor isn't the same as the security
      flavor the server requires for accessing the pseudo-fs.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      83ca7f5a
    • Chuck Lever's avatar
      NFS: Clean up nfs4_proc_get_rootfh · 2ed4b95b
      Chuck Lever authored
      The long lines with no vertical white space make this function
      difficult for humans to read.  Add a proper documenting comment
      while we're here.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      2ed4b95b
    • Chuck Lever's avatar
      NFS: Handle missing rpc.gssd when looking up root FH · 75bc8821
      Chuck Lever authored
      When rpc.gssd is not running, any NFS operation that needs to use a
      GSS security flavor of course does not work.
      
      If looking up a server's root file handle results in an
      NFS4ERR_WRONGSEC, nfs4_find_root_sec() is called to try a bunch of
      security flavors until one works or all reasonable flavors have
      been tried.  When rpc.gssd isn't running, this loop seems to fail
      immediately after rpcauth_create() craps out on the first GSS
      flavor.
      
      When the rpcauth_create() call in nfs4_lookup_root_sec() fails
      because rpc.gssd is not available, nfs4_lookup_root_sec()
      unconditionally returns -EIO.  This prevents nfs4_find_root_sec()
      from retrying any other flavors; it drops out of its loop and fails
      immediately.
      
      Having nfs4_lookup_root_sec() return -EACCES instead allows
      nfs4_find_root_sec() to try all flavors in its list.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: Bryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      75bc8821
    • Chuck Lever's avatar
      SUNRPC: Remove EXPORT_SYMBOL_GPL() from GSS mech switch · 5007220b
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      5007220b
    • Chuck Lever's avatar
      SUNRPC: Make gss_mech_get() static · 6599c0ac
      Chuck Lever authored
      gss_mech_get() is no longer used outside of gss_mech_switch.c.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      6599c0ac
    • Chuck Lever's avatar
      SUNRPC: Refactor nfsd4_do_encode_secinfo() · a77c806f
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Acked-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      a77c806f
    • Chuck Lever's avatar
      SUNRPC: Consider qop when looking up pseudoflavors · 83523d08
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      83523d08
    • Chuck Lever's avatar
      SUNRPC: Load GSS kernel module by OID · f783288f
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      f783288f
    • Chuck Lever's avatar
      SUNRPC: Introduce rpcauth_get_pseudoflavor() · 9568c5e9
      Chuck Lever authored
      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: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      9568c5e9
    • Chuck Lever's avatar
      SUNRPC: Define rpcsec_gss_info structure · fb15b26f
      Chuck Lever authored
      The NFSv4 SECINFO procedure returns a list of security flavors.  Any
      GSS flavor also has a GSS tuple containing an OID, a quality-of-
      protection value, and a service value, which specifies a particular
      GSS pseudoflavor.
      
      For simplicity and efficiency, I'd like to return each GSS tuple
      from the NFSv4 SECINFO XDR decoder and pass it straight into the RPC
      client.
      
      Define a data structure that is visible to both the NFS client and
      the RPC client.  Take structure and field names from the relevant
      standards to avoid confusion.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      fb15b26f
    • Chuck Lever's avatar
      NFS: Remove unneeded forward declaration · 72f4dc11
      Chuck Lever authored
      I've built with NFSv4 enabled and disabled.  This forward
      declaration does not seem to be required.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      72f4dc11
    • Chuck Lever's avatar
      SUNRPC: Missing module alias for auth_rpcgss.ko · 71afa85e
      Chuck Lever authored
      Commit f344f6df "SUNRPC: Auto-load RPC authentication kernel
      modules", Mon Mar 20 13:44:08 2006, adds a request_module() call
      in rpcauth_create() to auto-load RPC security modules when a ULP
      tries to create a credential of that flavor.
      
      In rpcauth_create(), the name of the module to load is built like
      this:
      
      	request_module("rpc-auth-%u", flavor);
      
      This means that for, say, RPC_AUTH_GSS, request_module() is looking
      for a module or alias called "rpc-auth-6".
      
      The GSS module is named "auth_rpcgss", and commit f344f6df does not
      add any new module aliases.  There is also no such alias provided in
      /etc/modprobe.d on my system (Fedora 16).  Without this alias, the
      GSS module is not loaded on demand.
      
      This is used by rpcauth_create().  The pseudoflavor_to_flavor() call
      can return RPC_AUTH_GSS, which is passed to request_module().
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      71afa85e
  5. 28 Mar, 2013 2 commits
    • Trond Myklebust's avatar
      NFSv4: Fix Oopses in the fs_locations code · 809b426c
      Trond Myklebust authored
      If the server sends us a pathname with more components than the client
      limit of NFS4_PATHNAME_MAXCOMPONENTS, more server entries than the client
      limit of NFS4_FS_LOCATION_MAXSERVERS, or sends a total number of
      fs_locations entries than the client limit of NFS4_FS_LOCATIONS_MAXENTRIES
      then we will currently Oops because the limit checks are done _after_ we've
      decoded the data into the arrays.
      
      Reported-by: fanchaoting<fanchaoting@cn.fujitsu.com>
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      809b426c
    • Trond Myklebust's avatar
      NFSv4: Fix another reboot recovery race · 91876b13
      Trond Myklebust authored
      If the open_context for the file is not yet fully initialised,
      then open recovery cannot succeed, and since nfs4_state_find_open_context
      returns an ENOENT, we end up treating the file as being irrecoverable.
      
      What we really want to do, is just defer the recovery until later.
      Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
      91876b13
  6. 27 Mar, 2013 1 commit
  7. 25 Mar, 2013 13 commits
  8. 21 Mar, 2013 3 commits