On Thu, Nov 3, 2011 at 5:16 PM, Myklebust, Trond <Trond.Myklebust@xxxxxxxxxx> wrote: >> It is ok to use keyring if that's deemed the right place for session keys, but I >> think you already have structures where you currently store them so I don't >> thik you necessarily need to change that part of the kernel implementation. > > No, but we still need to be able to do recovery of rpcsec_gss contexts once they are broken, and right now we have a major flaw due to the fact that recovery depends on a lot of small processes and data that is allowed to be swapped out at the moment when we need them the most (i.e. in a memory reclaim situation). > > If the server reboots while our client is in the middle of writing back a file (or several files), then the client needs to recover those rpcsec_gss contexts that authenticate the processes which own any dirty pages that remain to be written out. > Key security is an irrelevant concern once your kernel deadlocks in an OOM state. Ah, this problem. Hopefully the client has enough resources to thrash a lot in the process but still manage to recover. A better solution (see below) is possible, but will require more protocol/mechanism work. >> Currently credential caches are stored in files, is there a problem with that >> model ? Do you need access to credential caches from the kernel when >> under memory pressure ? > > Yes, there is a major problem with that model, and yes we do potentially need access to credential caches when in a recovery situation (which is a situation when we are usually under memory pressure). Ideally we could store in each RPCSEC_GSS context (not GSS context) enough state on the client side to recover quickly when the server reboots. How would we do this? Suppose the server gives the client a "ticket", and a key much like the Kerberos ticket session key is agreed upon or sent by the server -- that could be stored in the RPCSEC_GSS context and could be used to recover it quickly for recovery from server reboot. I'm eliding a lot of details here, but I believe this is fundamentally workable. A similar solution would be to store some GSS "sub-credential" in the RPCSEC_GSS context, but this would work for Kerberos and maybe not so well for other mechanisms -- and even with Kerberos, the service ticket might be expired when it comes time to recover. So I prefer the RPCSEC_GSS-level solution I mentioned above. If you agree with me on this then this sub-thread will be best moved to the NFSv4 WG, particularly if we agree on a protocol-level solution. Nico -- -- 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
