Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 02 October 2009 19:51 UTC
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9C93A682A; Fri, 2 Oct 2009 12:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.882
X-Spam-Level:
X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8uchLVGKT3q; Fri, 2 Oct 2009 12:51:58 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 32C8B3A67C1; Fri, 2 Oct 2009 12:51:58 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n92JrQg6001675; Fri, 2 Oct 2009 19:53:26 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n92JrQ8R024427; Fri, 2 Oct 2009 13:53:26 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n92JJhus003047; Fri, 2 Oct 2009 14:19:43 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n92JJg5u003046; Fri, 2 Oct 2009 14:19:42 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 02 Oct 2009 14:19:42 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <20091002191942.GJ887@Sun.COM>
References: <1372_1254340959_n8UK2bOg025386_20090930193620.GA902@Sun.COM> <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <65075E890F4E784CD4416173@atlantis.pc.cs.cmu.edu>
User-Agent: Mutt/1.5.7i
Cc: Craig Everhart <everhart@netapp.com>, secdir@ietf.org, Daniel Ellard <dellard@bbn.com>, nfsv4@ietf.org, Manoj Naik <manoj@almaden.ibm.com>, Renu Tewari <tewarir@us.ibm.com>, iesg@ietf.org, James Lentini <jlentini@netapp.com>
Subject: Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2009 19:51:59 -0000
On Wed, Sep 30, 2009 at 10:31:11PM -0400, Jeffrey Hutzelman wrote: > --On Wednesday, September 30, 2009 02:36:20 PM -0500 Nicolas Williams > <Nicolas.Williams@sun.com> wrote: > > > - A note that orphaned FSNs and FSLs cannot be easily distinguished > > from ones referenced by junctions and FSNs, respectively. Therefore > > objects will tend to pile up. This is a resource consumption > > consideration. Resource control issues are, IMO, a security > > consideration. > > I don't think this is a significant problem, or a security problem at all. > The fact that, once I have allocated my resources for an object, you might > decide to stop having any references to it, does not create a security > problem for me. This is analogous to my publishing a web page, and then > you later deciding not to link to it any more. I agree that orphaning over time is not a security problem. I was thinking more of the fact that to authorize someone to publish FSNs/FSLs in some NSDB is to authorize them to create unlimited amounts of garbage. Garbage collection being effectively impossible, the fact that authorization to publish is also authorization to consume all resources seems like a problem to me. One might want to implement resource controls at NSDBs ("Joe can create FSNs and FSLs in this NSDB, at the rate of 10 objects per-day" or "Jane can create up to 100 FSNs and FSLs in this NSDB"). One might also wish to have an optional way to document in an FSN the paths to junctions that are expected to reference the FSNs Similarly, an optional way to document in an FSL the FSNs that are expected to reference the FSL. Not that such documentation would be sufficient to make garbage collection possible; it'd only make it feasible to check _intended_ references. Nico --
- [secdir] draft-ietf-nfsv4-federated-fs-reqts-03 Nicolas Williams
- Re: [secdir] [nfsv4] draft-ietf-nfsv4-federated-f… Nicolas Williams
- Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-… Jeffrey Hutzelman
- Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-… James Lentini
- Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-… Nicolas Williams
- Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-… Jeffrey Hutzelman
- Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-… Nicolas Williams