[17390] in Kerberos_V5_Development
Re: GSSAPI Proxy initiative
daemon@ATHENA.MIT.EDU (Adamson, Andy)
Fri Nov 4 14:03:02 2011
From: "Adamson, Andy" <William.Adamson@netapp.com>
To: Nico Williams <nico@cryptonector.com>
Date: Fri, 4 Nov 2011 15:55:39 +0000
Message-ID: <CF863033-2ED4-4B68-B90C-54D315C67E27@netapp.com>
In-Reply-To: <CAK3OfOjqCjU4O--XwVBpSBE9pwwkyBEU6OiNLN8_dM6wYe5A1w@mail.gmail.com>
Content-Language: en-US
Content-ID: <CDB0824C27300F489BD82195C2570A1E@tahoe.netapp.com>
MIME-Version: 1.0
Cc: dhowells <dhowells@redhat.com>,
"<linux-nfs@vger.kernel.org>" <linux-nfs@vger.kernel.org>,
"Myklebust, Trond" <trond.myklebust@netapp.com>,
krbdev <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Nov 4, 2011, at 11:13 AM, Nico Williams wrote:
> On Thu, Nov 3, 2011 at 5:16 PM, Myklebust, Trond
> <Trond.Myklebust@netapp.com> 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.
You mean not to use the user Kerberos credential to re-establish the GSS context with the server?
> 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.
So re-establish the RPCSEC_GSS session lost at the server on server reboot by storing enough additional info on the client?
-->Andy
>
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
