Re: [PATCH 0/3] Remove function macros from nfs4_fs.h

From: Weston Andros Adamson <dros@primarydata.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Anna Schumaker <Anna.Schumaker@netapp.com>,
	Trond Myklebust <Trond.Myklebust@primarydata.com>,
	linux-nfs list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] Remove function macros from nfs4_fs.h
Date: Wed, 7 Jan 2015 13:47:53 -0500	[thread overview]
Message-ID: <2705333F-CCAE-44E2-BD42-76FEB452B764@primarydata.com> (raw)
In-Reply-To: <20150106190800.GB28003@fieldses.org>

> On Jan 6, 2015, at 2:08 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> 
> On Mon, Jan 05, 2015 at 03:31:46PM -0500, Weston Andros Adamson wrote:
>> These patches look good to me, but have you tested them? ;)
>> 
>> I mean, does anyone have a server that implements SP4_MACH_CRED to test against?
>> When I originally developed this feature, I tested against a hacked nfsd…
>> that code was really ugly (not ready for upstreaming), but allowed me to test the client
>> feature.
>> 
>> IRRC the server side is difficult because the server has to keep stateid to credential
>> mappings, so when the machine cred was used it could check access against the acting cred. 
>> 
>> If there aren’t any servers to test this against, maybe we remove this feature? It can always
>> be revived once there is a server to test against.
> 
> The Linux server should support MACH_CRED as of
> 57266a6e916e2522ea61758a3ee5576b60156791 "nfsd4: implement minimal
> SP4_MACH_CRED".  (Well, plus some later bugfixes.)  But I think anything
> since 3.14 should be OK.
> 
> That said, I wouldn't be surprised if it has problems.  But please do
> test against that and let me know....
> 
> --b.

Ah, right, but only for state operations that don’t touch the filesystem:

OP_BIND_CONN_TO_SESSION
OP_EXCHANGE_ID
OP_CREATE_SESSION
OP_DESTROY_SESSION
OP_DESTROY_CLIENTID

Which is not that interesting, since the client should already be using the machine cred
with these operations.

What is interesting is supporting write and commit (and associated ops, i.e. sequence).
That way when a client is doing buffered writes and the user cred expires, it can flush the
locally cached data. This is what the linux client SP4_MACH_CRED feature focused on.

I think implementing SP4_MACH_CRED for these operations has the issue I mentioned
earlier: the fh_verify path will have to check credentials against some cached credential
(tied to the stateid), because request will contain the machine credential and not the user
credential that previous writes (before cred expiration) used.

-dros