If rpc.gssd sends us an acceptor name string trailing the context token,
stash it as part of the context.
Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

RPC_MAX_AUTH_SIZE is scattered around several places.  Better to set it
once in the auth code, where this kind of estimate should be made.  And
while we're at it we can leave it zero when we're not using krb5i or
krb5p.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We're not taking a reference in the case where _gss_mech_get_by_pseudoflavor
loops without finding the correct rpcsec_gss flavour, so why are we
releasing it?
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Mostly scripted conversion of the smp_mb__* barriers.
Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-arch@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

In gss_alloc_msg(), if the call to gss_encode_v1_msg() fails, we
want to release the reference to the pipe_version that was obtained
earlier in the function.

Fixes: 9d3a2260 (SUNRPC: Fix buffer overflow checking in...)
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Fix a race in which the RPC client is shutting down while the
gss daemon is processing a downcall. If the RPC client manages to
shut down before the gss daemon is done, then the struct gss_auth
used in gss_release_msg() may have already been freed.

Link: http://lkml.kernel.org/r/1392494917.71728.YahooMailNeo@web140002.mail.bf1.yahoo.comReported-by: NJohn <da_audiophile@yahoo.com>
Reported-by: NBorislav Petkov <bp@alien8.de>
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

An infinite loop is caused when nfs4_establish_lease() fails
with -EACCES. This causes nfs4_handle_reclaim_lease_error()
to sleep a bit and resets the NFS4CLNT_LEASE_EXPIRED bit.
This in turn causes nfs4_state_manager() to try and
reestablished the lease, again, again, again...

The problem is a valid RPCSEC_GSS client is being created when
rpc.gssd is not running.

Link: http://lkml.kernel.org/r/1392066375-16502-1-git-send-email-steved@redhat.com
Fixes: 0ea9de0e (sunrpc: turn warn_gssd() log message into a dprintk())
Reported-by: NSteve Dickson <steved@redhat.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

The original printk() made sense when the GSSAPI codepaths were called
only when sec=krb5* was explicitly requested. Now however, in many cases
the nfs client will try to acquire GSSAPI credentials by default, even
when it's not requested.

Since we don't have a great mechanism to distinguish between the two
cases, just turn the pr_warn into a dprintk instead. With this change we
can also get rid of the ratelimiting.

We do need to keep the EXPORT_SYMBOL(gssd_running) in place since
auth_gss.ko needs it and sunrpc.ko provides it. We can however,
eliminate the gssd_running call in the nfs code since that's a bit of a
layering violation.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

Replace hardcoded lowest common multiple algorithm by the lcm()
function in kernel lib.
Signed-off-by: NLuis Henriques <luis.henriques@canonical.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We can achieve the same result with a cmpxchg(). This also fixes a
potential race in use_gss_proxy(). The value of sn->use_gss_proxy could
go from -1 to 1 just after we check it in use_gss_proxy() but before we
acquire the spinlock. The procfile write would end up returning success
but the value would flip to 0 soon afterward. With this method we not
only avoid locking but the first "setter" always wins.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

An nfsd thread can call use_gss_proxy and find it set to '1' but find
gssp_clnt still NULL, so that when it attempts the upcall the result
will be an unnecessary -EIO.

So, ensure that gssp_clnt is created first, and set the use_gss_proxy
variable only if that succeeds.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

It doesn't make much sense to make reads from this procfile hang. As
far as I can tell, only gssproxy itself will open this file and it
never reads from it. Change it to just give the present setting of
sn->use_gss_proxy without waiting for anything.

Note that we do not want to call use_gss_proxy() in this codepath
since an inopportune read of this file could cause it to be disabled
prematurely.

Cc: stable@vger.kernel.org
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Now that we have a more reliable method to tell if gssd is running, we
can replace the sn->gssd_running flag with a function that will query to
see if it's up and running.

There's also no need to attempt an upcall that we know will fail, so
just return -EACCES if gssd isn't running. Finally, fix the warn_gss()
message not to claim that that the upcall timed out since we don't
necesarily perform one now when gssd isn't running, and remove the
extraneous newline from the message.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Otherwise RPCSEC_GSS_DESTROY messages are not sent.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

In gss_encode_v1_msg, it is pointless to BUG() after the overflow has
happened. Replace the existing sprintf()-based code with scnprintf(),
and warn if an overflow is ever triggered.

In gss_encode_v0_msg, replace the runtime BUG_ON() with an appropriate
compile-time BUILD_BUG_ON.
Reported-by: NBruce Fields <bfields@fieldses.org>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Add the missing 'break' to ensure that we don't corrupt a legacy 'v0' type
message by appending the 'v1'.

Cc: Bruce Fields <bfields@fieldses.org>
Cc: stable@vger.kernel.org
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

As Bruce points out in RFC 4121, section 4.2.3:

   "In Wrap tokens that provide for confidentiality, the first 16 octets
    of the Wrap token (the "header", as defined in section 4.2.6), SHALL
    be appended to the plaintext data before encryption.  Filler octets
    MAY be inserted between the plaintext data and the "header.""

...and...

   "In Wrap tokens with confidentiality, the EC field SHALL be used to
    encode the number of octets in the filler..."

It's possible for the client to stuff different data in that area on a
retransmission, which could make the checksum come out wrong in the DRC
code.

After decrypting the blob, we should trim off any extra count bytes in
addition to the checksum blob.
Reported-by: N"J. Bruce Fields" <bfields@fieldses.org>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

A couple times recently somebody has noticed that we're ignoring a
sequence number here and wondered whether there's a bug.

In fact, there's not.  Thanks to Andy Adamson for pointing out a useful
explanation in rfc 2203.  Add comments citing that rfc, and remove
"seqnum" to prevent static checkers complaining about unused variables.
Reported-by: NAndi Kleen <andi@firstfloor.org>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Reported-by: NAndi Kleen <andi@firstfloor.org>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

For every other problem here we bail out with an error, but here for
some reason we're setting a negative cache entry (with, note, an
undefined expiry).

It seems simplest just to bail out in the same way as we do in other
cases.

Cc: Simo Sorce <simo@redhat.com>
Reported-by: NAndi Kleen <andi@firstfloor.org>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We depend on the xdr decoder to set this pointer, but if we error out
before we decode this piece it could be left NULL.

I think this is probably tough to hit without a buggy gss-proxy.
Reported-by: NAndi Kleen <andi@firstfloor.org>
Cc: Simo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

This fixes a regression since  eb6dc19d
"RPCSEC_GSS: Share all credential caches on a per-transport basis" which
could cause an occasional oops in the nfsd code (see below).

The problem was that an auth was left referencing a client that had been
freed.  To avoid this we need to ensure that auths are shared only
between descendants of a common client; the fact that a clone of an
rpc_client takes a reference on its parent then ensures that the parent
client will last as long as the auth.

Also add a comment explaining what I think was the intention of this
code.

  general protection fault: 0000 [#1] PREEMPT SMP
  Modules linked in: rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl lockd sunrpc
  CPU: 3 PID: 4071 Comm: kworker/u8:2 Not tainted 3.11.0-rc2-00182-g025145f #1665
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  Workqueue: nfsd4_callbacks nfsd4_do_callback_rpc [nfsd]
  task: ffff88003e206080 ti: ffff88003c384000 task.ti: ffff88003c384000
  RIP: 0010:[<ffffffffa00001f3>]  [<ffffffffa00001f3>] rpc_net_ns+0x53/0x70 [sunrpc]
  RSP: 0000:ffff88003c385ab8  EFLAGS: 00010246
  RAX: 6b6b6b6b6b6b6b6b RBX: ffff88003af9a800 RCX: 0000000000000002
  RDX: ffffffffa00001a5 RSI: 0000000000000001 RDI: ffffffff81e284e0
  RBP: ffff88003c385ad8 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000015 R12: ffff88003c990840
  R13: ffff88003c990878 R14: ffff88003c385ba8 R15: ffff88003e206080
  FS:  0000000000000000(0000) GS:ffff88003fd80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007fcdf737e000 CR3: 000000003ad2b000 CR4: 00000000000006e0
  Stack:
   ffffffffa00001a5 0000000000000006 0000000000000006 ffff88003af9a800
   ffff88003c385b08 ffffffffa00d52a4 ffff88003c385ba8 ffff88003c751bd8
   ffff88003c751bc0 ffff88003e113600 ffff88003c385b18 ffffffffa00d530c
  Call Trace:
   [<ffffffffa00001a5>] ? rpc_net_ns+0x5/0x70 [sunrpc]
   [<ffffffffa00d52a4>] __gss_pipe_release+0x54/0x90 [auth_rpcgss]
   [<ffffffffa00d530c>] gss_pipe_free+0x2c/0x30 [auth_rpcgss]
   [<ffffffffa00d678b>] gss_destroy+0x9b/0xf0 [auth_rpcgss]
   [<ffffffffa000de63>] rpcauth_release+0x23/0x30 [sunrpc]
   [<ffffffffa0001e81>] rpc_release_client+0x51/0xb0 [sunrpc]
   [<ffffffffa00020d5>] rpc_shutdown_client+0xe5/0x170 [sunrpc]
   [<ffffffff81098a14>] ? cpuacct_charge+0xa4/0xb0
   [<ffffffff81098975>] ? cpuacct_charge+0x5/0xb0
   [<ffffffffa019556f>] nfsd4_process_cb_update.isra.17+0x2f/0x210 [nfsd]
   [<ffffffff819a4ac0>] ? _raw_spin_unlock_irq+0x30/0x60
   [<ffffffff819a4acb>] ? _raw_spin_unlock_irq+0x3b/0x60
   [<ffffffff810703ab>] ? process_one_work+0x15b/0x510
   [<ffffffffa01957dd>] nfsd4_do_callback_rpc+0x8d/0xa0 [nfsd]
   [<ffffffff8107041e>] process_one_work+0x1ce/0x510
   [<ffffffff810703ab>] ? process_one_work+0x15b/0x510
   [<ffffffff810712ab>] worker_thread+0x11b/0x370
   [<ffffffff81071190>] ? manage_workers.isra.24+0x2b0/0x2b0
   [<ffffffff8107854b>] kthread+0xdb/0xe0
   [<ffffffff819a4ac0>] ? _raw_spin_unlock_irq+0x30/0x60
   [<ffffffff81078470>] ? __init_kthread_worker+0x70/0x70
   [<ffffffff819ac7dc>] ret_from_fork+0x7c/0xb0
   [<ffffffff81078470>] ? __init_kthread_worker+0x70/0x70
  Code: a5 01 00 a0 31 d2 31 f6 48 c7 c7 e0 84 e2 81 e8 f4 91 0a e1 48 8b 43 60 48 c7 c2 a5 01 00 a0 be 01 00 00 00 48 c7 c7 e0 84 e2 81 <48> 8b 98 10 07 00 00 e8 91 8f 0a e1 e8
  +3c 4e 07 e1 48 83 c4 18
  RIP  [<ffffffffa00001f3>] rpc_net_ns+0x53/0x70 [sunrpc]
   RSP <ffff88003c385ab8>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Fix the declaration of the gss_auth_hash_table so that it creates
a 16 bucket hashtable, as I had intended.
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

In theory the linux cred in a gssproxy reply can include up to
NGROUPS_MAX data, 256K of data.  In the common case we expect it to be
shorter.  So do as the nfsv3 ACL code does and let the xdr code allocate
the pages as they come in, instead of allocating a lot of pages that
won't typically be used.
Tested-by: NSimo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will
take up more than a page.  We therefore need to allocate an array of
pages to hold the reply instead of trying to allocate a single huge
buffer.
Tested-by: NSimo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

The encoding of linux creds is a bit confusing.

Also: I think in practice it doesn't really matter whether we treat any
of these things as signed or unsigned, but unsigned seems more
straightforward: uid_t/gid_t are unsigned and it simplifies the ngroups
overflow check.
Tested-by: NSimo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

We can use the normal coding infrastructure here.

Two minor behavior changes:

	- we're assuming no wasted space at the end of the linux cred.
	  That seems to match gss-proxy's behavior, and I can't see why
	  it would need to do differently in the future.

	- NGROUPS_MAX check added: note groups_alloc doesn't do this,
	  this is the caller's responsibility.
Tested-by: NSimo Sorce <simo@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Most of the time an error from the credops crvalidate function means the
server has sent us a garbage verifier. The gss_validate function is the
exception where there is an -EACCES case if the user GSS_context on the client
has expired.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

This patch provides the RPC layer helper functions to allow NFS to manage
data in the face of expired credentials - such as avoiding buffered WRITEs
and COMMITs when the gss context will expire before the WRITEs are flushed
and COMMITs are sent.

These helper functions enable checking the expiration of an underlying
credential key for a generic rpc credential, e.g. the gss_cred gss context
gc_expiry which for Kerberos is set to the remaining TGT lifetime.

A new rpc_authops key_timeout is only defined for the generic auth.
A new rpc_credops crkey_to_expire is only defined for the generic cred.
A new rpc_credops crkey_timeout is only defined for the gss cred.

Set a credential key expiry watermark, RPC_KEY_EXPIRE_TIMEO set to 240 seconds
as a default and can be set via a module parameter as we need to ensure there
is time for any dirty data to be flushed.

If key_timeout is called on a credential with an underlying credential key that
will expire within watermark seconds, we set the RPC_CRED_KEY_EXPIRE_SOON
flag in the generic_cred acred so that the NFS layer can clean up prior to
key expiration.

Checking a generic credential's underlying credential involves a cred lookup.
To avoid this lookup in the normal case when the underlying credential has
a key that is valid (before the watermark), a notify flag is set in
the generic credential the first time the key_timeout is called. The
generic credential then stops checking the underlying credential key expiry, and
the underlying credential (gss_cred) match routine then checks the key
expiration upon each normal use and sets a flag in the associated generic
credential only when the key expiration is within the watermark.
This in turn signals the generic credential key_timeout to perform the extra
credential lookup thereafter.
Signed-off-by: NAndy Adamson <andros@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Ensure that all struct rpc_clnt for any given socket/rdma channel
share the same RPCSEC_GSS/krb5,krb5i,krb5p caches.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Ensure that if an rpc_clnt owns more than one RPCSEC_GSS-based authentication
mechanism, then those caches will share the same 'gssd' upcall pipe.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

If an error condition occurs on rpc_pipefs creation, or the user mounts
rpc_pipefs and then unmounts it, then the dentries in struct gss_auth
need to be reset to NULL so that a second call to gss_pipes_dentries_destroy
doesn't try to free them again.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Don't pass the rpc_client as a parameter, when what we really want is
the net namespace.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The clnt->cl_principal is being used exclusively to store the service
target name for RPCSEC_GSS/krb5 callbacks. Replace it with something that
is stored only in the RPCSEC_GSS-specific code.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

Optimise away gss_encode_msg: we don't need to look up the pipe
version a second time.

Save the gss target name in struct gss_auth. It is a property of the
auth cache itself, and doesn't really belong in the rpc_client.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>

The change made to rsc_parse() in
0dc1531a "svcrpc: store gss mech in
svc_cred" should also have been propagated to the gss-proxy codepath.
This fixes a crash in the gss-proxy case.
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

mech_oid.data is an array, not kmalloc()'d memory.

Cc: stable@vger.kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>

Uninitialized stack data was being used as the destination for memcpy's.

Longer term we'll just delete some of this code; all we're doing is
skipping over xdr that we don't care about.

Cc: stable@vger.kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>