Date: Mon, 5 Jul 2010 19:25:20 +1000 (EST) From: James Morris <jmorris@namei.org> To: "Robert N. M. Watson" <rwatson@freebsd.org> Cc: freebsd-hackers@freebsd.org, David Quigley <dpquigl@tycho.nsa.gov>, Trond Myklebust <trond.myklebust@fys.uio.no>, "J. Bruce Fields" <bfields@fieldses.org>, Chuck Lever <chuck.lever@oracle.com>, Rick Macklem <rmacklem@freebsd.org> Subject: Re: Extended attributes for NFSv3 - possible Linux interop Message-ID: <alpine.LRH.2.00.1007051907090.27098@tundra.namei.org> In-Reply-To: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> References: <alpine.LRH.2.00.1007021025580.2699@tundra.namei.org> <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<jmorris@namei.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.00.1007051907090.27098>