Re: [nfsv4] Path forward for flex-files
Benjamin Kaduk <kaduk@mit.edu> Mon, 07 August 2017 23:29 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4091129B25 for <nfsv4@ietfa.amsl.com>; Mon, 7 Aug 2017 16:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOdhHWb4-mg0 for <nfsv4@ietfa.amsl.com>; Mon, 7 Aug 2017 16:29:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34058128C9C for <nfsv4@ietf.org>; Mon, 7 Aug 2017 16:29:31 -0700 (PDT)
X-AuditID: 12074422-36dff7000000420c-cc-5988f7dabe9e
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 24.6F.16908.AD7F8895; Mon, 7 Aug 2017 19:29:30 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v77NTTTU002434; Mon, 7 Aug 2017 19:29:29 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v77NTPW8027735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Aug 2017 19:29:27 -0400
Date: Mon, 07 Aug 2017 18:29:25 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>, Olga Kornievskaia <aglo@citi.umich.edu>
Message-ID: <20170807232925.GK70977@kduck.kaduk.org>
References: <YTXPR01MB01898B5A88D647118989E5CEDDB50@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YTXPR01MB01898B5A88D647118989E5CEDDB50@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6nrnvre0ekwdfv/BZrHz1lt1i+Zyu7 xez3j1gtHi67xuTA4rGmtZPFY8mSn0we8+fKefzevJcpgCWKyyYlNSezLLVI3y6BK2PqD8mC 2/wVd0/fZWlgvMHTxcjJISFgItF79iljFyMXh5DAYiaJJYtnMkE4Gxgllp6fzg7hXGGS+Hrk IStIC4uAikRb80c2EJsNyG7ovswMYosIqEtsXt0PZjML1Euse7EJrF5YwEBi3/H9QPUcHLxA 687+zAEJCwnESNx+txesnFdAUOLkzCcsEK1aEjf+vWQCKWcWkJZY/o8DJMwpECux78FisK2i AsoS8/atYpvAKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXVy80s0UtN Kd3ECA5kF6UdjBP/eR1iFOBgVOLhZcjsiBRiTSwrrsw9xCjJwaQkysu5BSjEl5SfUpmRWJwR X1Sak1p8iFGCg1lJhJfnG1CONyWxsiq1KB8mJc3BoiTOK67RGCEkkJ5YkpqdmlqQWgSTleHg UJLgvQvSKFiUmp5akZaZU4KQZuLgBBnOAzT8P9jw4oLE3OLMdIj8KUZFKXHeepCEAEgiozQP rheUaCSy99e8YhQHekWY9ylIFQ8wScF1vwIazAQ0+E1iK8jgkkSElFQD4wKvgimLlOfsu274 mddiQVqY/SZRKfYbybIhT6+/5jrHPe3IhTuV4gpeKdvqXM2WLTuv++1w4qb8iR/OW+VNFzkr H3thawMfz5zrB3k1/kUL/Tw6d820+ZWnz6WVRUtv6w+T1E1nvv5KpVIqZ+nWN9YGTGZijko+ erVlubsfu5k/nGfduPN2lhJLcUaioRZzUXEiAC5DOL0PAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/r33ER2f7Kra_odeqzkDrl6BOzk4>
Subject: Re: [nfsv4] Path forward for flex-files
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 23:29:33 -0000
On Mon, Aug 07, 2017 at 11:03:44PM +0000, Rick Macklem wrote: > Olga Kornievskaia wrote: > [lots of stuff snipped] > > That's the problem you need something in the structure to pass back > > the ticket (TGT is not necessary. service ticket would do). Besides > > the ticket you need to send the other pieces. > Oh, the reason I was thinking of using TGT tickets was related to my comment > at the end about deleting the synthetic principal to do fencing. > > I was thinking of a TGT with a fairly long lifetime (as long as layouts need > to be valid) and a service ticket with a short lifetime, so that the client keeps > using the TGT to get a new service ticket/GSS-context. > Then, this would fail when the synthetic principal is deleted in the KDC. > (I don't think that renewable tickets are needed, that was a brain fart on my part.) The solution space looks rather different whether the synthetic principals are actually being created/deleted on the KDC or synthesized using the data server's keytab. In the case where the KDC is involved, ticket lifetimes and principal existence are somewhat annoying to manage -- in order to have a long-lived TGT but get short-lived service tickets, with (e.g.) an MIT krb5 KDC you'd either have to use a custom policy plugin to limit the service ticket lifetime, or set the max lifetime on the data server's service principal to that short lifetime (which has annoying effects for anything that's supposed to be connecting to it directly). As far as principal management, the fencing would not be particularly instantaneous -- the current ticket would have to expire, and the principal deletion/deactivation would need to propagate to all KDCs in the realm. IIRC it's also possible to have a KDC that doesn't even pull up the client principal's database entry when generating a service ticket from a TGT (i.e., it would not actually notice the deleted client principal!), which of course would not work for this use case. -Ben
- [nfsv4] Path forward for flex-files David Noveck
- Re: [nfsv4] Path forward for flex-files Rick Macklem
- Re: [nfsv4] Path forward for flex-files Rick Macklem
- Re: [nfsv4] Path forward for flex-files Olga Kornievskaia
- Re: [nfsv4] Path forward for flex-files Thomas Haynes
- Re: [nfsv4] Path forward for flex-files Rick Macklem
- Re: [nfsv4] Path forward for flex-files Rick Macklem
- Re: [nfsv4] Path forward for flex-files Benjamin Kaduk
- Re: [nfsv4] Path forward for flex-files Benjamin Kaduk
- Re: [nfsv4] Path forward for flex-files Benjamin Kaduk
- Re: [nfsv4] Path forward for flex-files Rick Macklem
- Re: [nfsv4] Path forward for flex-files Benjamin Kaduk
- Re: [nfsv4] Path forward for flex-files Rick Macklem