> On Jan 6, 2015, at 2:08 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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 -- 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
