On Tue, Aug 06, 2013 at 05:08:26PM -0400, Weston Andros Adamson wrote:
> These patches are the initial client-side SP4_MACH_CRED implementation.
>
> Patch 1 is a repost with a few cleanups
>
> Patch 2 adds the sp4 handler that replaces the cred on an rpc message (and
> picks the right rpc_clnt). Note that for now, we always use the machine cred
> if supported - we could only use it if the user cred expires, but this is
> simple and spec compliant.
So anything on the spo_may_enforce_list will *always* use the machine
cred?
I wonder.... This is within the letter of the spec, but the spec also
does also give the motivation. ("The purpose of spo_must_allow is to
allow clients to solve the following conundrum....")
I'd worry that server implementors will also stick to the letter of the
spec and allow this, but also design under the assumption that this is a
rare case. (E.g., allow the access but trigger some extra auditing??)
I'd probably try it this way first too, as you say, it's simpler, but I
wonder whether it's really what we want to client doing all the time.
> Patch 3-5 implement SP4_MACH_CRED "features":
> - cleanup - CLOSE and LOCKU use machine cred
> - secinfo - SECINFO and SECINFO_NO_NAME use machine cred
> - stateid - TEST_STATEID and FREE_STATEID use machine cred
>
> There are three more features that I've been working on, but need to be tested
> before I post:
> - commit - COMMIT uses machine cred
> - write - WRITE uses machine cred, forces stable writes unless commit feature
> is also enabled
> - recovery - OPEN and LOCK can use machine cred - only in recovery.
>
> The commit and write cases should be easy to test against a hacked nfsd, but
> I need to think more about how to test the recovery stuff...
Can't you just hack nfsd to allow those ops and then do a server
restart, or try Bryan's fault-injection interface if you want to test
some more exotic recovery scenario?
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
