Date: Fri, 2 Jul 2010 10:34:42 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: James Morris <jmorris@namei.org> Cc: freebsd-hackers@freebsd.org, Rick Macklem <rmacklem@FreeBSD.org> Subject: Re: Extended attributes for NFSv3 - possible Linux interop Message-ID: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> In-Reply-To: <alpine.LRH.2.00.1007021025580.2699@tundra.namei.org> References: <alpine.LRH.2.00.1007021025580.2699@tundra.namei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 Jul 2010, at 01:44, James Morris wrote:
> I've been working on an implementation of extended attributes for the=20=
> Linux NFSv3 code, initially based on the IRIX implementation [1]. =
This is=20
> being developed as a sideband protocol ('XATTR'), to convey simple=20
> name/value string extended attributes over the network.
>=20
> Here's a link to the latest patchset:
> http://lwn.net/Articles/392944/
>=20
> and my LinuxCon slides on the topic from last year:
> http://namei.org/presentations/linuxcon09_nfsv3xattrs.pdf
>=20
> The code is at a working prototype stage, and the next step is to =
begin=20
> formalizing the protocol.
>=20
> I'd like to try and determine whether there is any interest in this =
XATTR=20
> protocol for FreeBSD (which has a similar extended attribute model to=20=
> Linux), and then whether we should develop an informal specification =
to=20
> cater for interoperability between FreeBSD and Linux.=20
>=20
> [1] http://oss.sgi.com/projects/ob1.nuked/src/nfs/
Hi Other Robert:
I think it's a good idea. BTW, Mac OS X *also* supports meta-data =
extended attributes (not just forks) on HFS+ and friends, and similarly =
uses them to hold ACLs, MAC labels (using a port of FreeBSD's MAC =
Framework), etc. My hazy recollection is that they are stored inside a =
specially designated file fork, but that might be a misrecollection. So =
the Apple folk might be interested as well so we should try to get them =
in the loop -- they certainly also understand the file fork vs. =
meta-data EA tension. Their API is a bit more like the Linux API than =
the FreeBSD API when it comes to meta-data -- minor spelling =
differences. Historically other systems have also done IRIX meta-data =
EAs (which is where both the Linux and FreeBSD work found its model) =
including HPFS on OS 2. On a similar note, we should engage the NetApp =
folk and Sun folk; I'm suspect NetApp does not support our notion of =
meta-data EAs with atomicity properties, and I'm pretty sure Sun =
doesn't. However, if there will be standards, getting their buy-in early =
makes sense.
FreeBSD currently doesn't implement Sun's NFSv3 ACL extension, which I =
believe is what Linux implements, but probably should. If we're going to =
standardize the EA RPC interface, we should also standardize the ACL =
interface, and then someone in FreeBSD land can implement it as well =
:-). And that probably means extending the existing ACL extension: we =
will need to support NFSv4 ACLs with NFSv3, since we can use both POSIX =
and NFSv4 ACLs on disk in FreeBSD, and the leaning is towards NFSv4 ACLs =
for everything these days. Mac OS X uses NTFS ACLs, which are (in many =
ways) similar to NFSv4 ACLs and also might be interested.
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.
On a related note, it might make sense to review current consumers of =
the EA API and decide if we want to standardize a system call API as =
well -- current API consumers have a bit of a hard time right now due to =
the differences across all major UNIX platforms, which is silly. =
Especially if we have an NFS EA RPC in flight, taking this opportunity =
to nail down a new, portable, system call API would be opportune. =
Obviously, we'd need to think about the namespace issue, but also =
atomicity issues: one of the guarantees we provide in FreeBSD is that EA =
writes are atomic with respect to other simultaneous users, and we also =
try really hard to provide strong atomicity properties with respect to =
persistence (i.e., in the event of a crash you will get $oldlabel for =
MAC, or $newlabel, but not half of each). Further, we offer =
transactional semantics in our VFS layer, but that isn't exposed to =
userspace. This allows atomic update of several EAs at once as required =
by our MAC environment (if you run with two policies and both update =
labels simultaneously, it will be atomic). Something to think about =
offering via system calls, I suppose, but I worry that pushes the edge a =
bit far on UNIX APIs. :-)
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...
I've added Rick Macklem to the CC line since he did both our original =
NFS code, and our more recent NFSv4 code, and is a long-time participant =
in the NFS community.
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). Any chance you might be at USENIX Security in DC this August?
Another Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98BC47A1-7A14-48EF-8C4B-EFB7EF063853>