From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 5 09:25:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A12B1065670; Mon, 5 Jul 2010 09:25:29 +0000 (UTC) (envelope-from jmorris@namei.org) Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) by mx1.freebsd.org (Postfix) with ESMTP id E6A488FC0C; Mon, 5 Jul 2010 09:25:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id o659PKc5027191; Mon, 5 Jul 2010 05:25:20 -0400 Date: Mon, 5 Jul 2010 19:25:20 +1000 (EST) From: James Morris To: "Robert N. M. Watson" In-Reply-To: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> Message-ID: References: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, David Quigley , Trond Myklebust , "J. Bruce Fields" , Chuck Lever , Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 09:25:29 -0000 On Fri, 2 Jul 2010, Robert N. M. Watson wrote: > Something that's always worried me about the Mac OS X and Linux EA APIs > is the namespace issue: in FreeBSD, we have an explicit enumeration of > namespaces reflected in an argument to the system calls -- in our case, > an int, but you could imagine other options. As I recall, Linux (perhaps > also IRIX?) designated "system" EAs via an interpretation of names ('$' > prefix). Mac OS X doesn't do this, or at least, the namespace is > different. I wonder given the portability concerns: would it make sense > to make the NFS wire protocol identify the namespace explicitly, and > then OSes can map to/from their local implementation semantics? Linux > could strip the '$' before putting the name on the wire and select the > system namespace in the RPC, whereas FreeBSD could map its local notion > of EXTATTR_NAMESPACE_SYSTEM into whatever the NFS constant is. Then when > it pops out the other end, mapping back to local semantics would occur. > This seems more likely to get the security right (in FreeBSD, writing to > the system namespace requires a specific privilege in our privilege > system), and is an adequate superset of all the APIs to be useful. [added the Linux maintainers] In my current implementation, the server only provides storage for EAs, and never interprets them. Otherwise, security becomes very difficult and possibly not viable with such a basic general approach (i.e. a side simple protocol). The separate NFSv4 Labeled NFS effort is an example of how to go beyond simple sever storage. At Trond's suggestion, I've implemented a special sever namespace in the Linux code, where all client EAs are stored, so: system.foo on the client is transmitted over the wire as such, and then the server stores the EA in nfsd.system.foo. This is done transparently to the client, and the nfsd. namespace is privileged on the server, and also never interpreted by the server. I'd suggest generalizing this for a specification, to allow for a variety of possible server implementations (including where the server does not even support EAs locally itself). > I'm happy to help contribute to the writing on an Internet Draft and/or > RFC -- the lack of NFS support for EAs (and the EA vs. file fork > confusion) have long caused me frustration, and with systems like > SELinux, our various MAC policies, and all sorts of other things > floating around, there's a strong motivation to fix this ... in a > portable way! I'm just sorry I haven't gotten to this sooner... The IETF process is closed for NFSv3, so in this case, it would be not an ID or RFC. > Could we set up a phone call to chat about all this? Things are really > busy here this summer, both for good and bad reasons, but a phone call > on East Coast time is usually arrangeable for me (I'm mostly on British > time). I'm in Sydney, btw. We could set up a call with potential stake-holders. > Any chance you might be at USENIX Security in DC this August? No, but I will be in Boston for LinuxCon approx. 9th-12th August. -- James Morris