Re: ACL handling for NFSv4
Re: ACL handling for NFSv4
- Subject: Re: ACL handling for NFSv4
- From: Terry Lambert <email@hidden>
- Date: Thu, 20 Nov 2008 12:33:50 -0800
On Nov 19, 2008, at 7:48 AM, Michael Smith wrote:
On Nov 13, 2008, at 12:38 PM, Rick Macklem wrote:
I finally have an NFSv4 server that includes support for NFSv4
ACLs, so I
was hoping to tweak my NFSv4 Leopard client (http://code.google.com/p/macnfsv4
) to make use of them. (Note this is an
experimental open source project using a Kext that already goes
beyond the
KPIs, so I realize that the internal interfaces may change at any
time...)
Looking at xnu-1228 sources, it seems that getting an ACL from a file
system is done via vnode_getattr(), but is set via vn_setxattr()
setting
KAUTH_FILESEC_XATTR. Is that correct?
No, the operations are symmetric. If vnode_setattr() returns
without having claimed to have supported the ACL set, the fallback
path will attempt to save the ACL using an extended attribute.
Likewise if the ACL is requested and vnode_getattr() returns without
claiming to have supported the request, the fallback will look for
an EA.
And the fallback for extended attributes will create ._ files.
ACLs are dealt with in terms of filesec_t's, whise contents are
intended to be considered opaque in user space, and for which there
are no user space functions for setting certain parts of them.
In practice, there is only check/read/modify/write, where if the check
fails you do not do the read/modify/write, and if the check succeeds,
you do the read/modify/write, and if you want to set one, you do a
read/modify/write and the read cons's up the information that you
can't create in user space, and you modify that to add the ACEs you
want - the chmod and ls source code is a good reference.
Best practice is to not use these fields, and to not set their
validity flags when round-tripping in/out of filesec_t's
(kauth_filesec's, in non-pointer references).
NOTE TO CASUAL ARCHIVE READERS: UNLESS YOU ARE A FILESYSTEM
IMPLEMENTOR RUNNING IN THE KERNEL, LEAVE THESE THE HECK ALONE!!!
Part of my problem is that I don't have extended attribute support in
the server, so I don't have a way to store/retrieve the guid_t owner
and group fields in kauth_filesec on the server, which leads me to...
Check with Terry, however it's probably safe to either ignore these
or ask the local system to translate the UID/GID you have into GUIDs.
As long as these are not set, then they won't be an issue. The
filesec_t is the contract between user space (libc POSIX 1003.1e,
generally) and the kernel. Unless you return the values, the read/
modify/write from before won't set them, and so there will be no need
to fake them up.
What are the guid_t owner and group fields of a kauth_filesec and is
there a way a client can map those to/from uid/gid or do they have to
be stored/retrieved from the file system? (If I have to store/
retrieve
them, I suspect I'm snookered.)
There's a local translation service. See the kauth_* functions.
Specifically, the kernel does not explicitly know about uuids/guids/
ntsids. The kernel know about integers, and it know how to ask that
integers be translated to/from these things. All POSIX enforcement is
based on integers, all credential information (other than MAC labels)
is handled as integers, and you can't get at MAC labels and shouldn't
try, due to scoping rules.
So if I have an ACE I am trying to set, since the storage format
*happens* to be GUID, then we translate the integer for the gid and
uid of the current credential into a GUID for the purposes of storage.
For the purposes of comparison on lookup, we then convert the current
credential into a GUID (in general, the uid, since that is the primary
identity in a credential), and compare the GUID to the GUID in the
ACE. This is handled in xnu in bsd/kern/
kern_authorization.c:kauth_acl_evaluate().
Although there are support functions for translating the other
direction, e.g. kauth_cred_guid2uid(), and kauth_cred_guid2gid() no
one uses them, and I would, in fact, like to keep things that way.
The only exception to this is kauth_cred_guid2gid() is used by
kauth_cred_ismember_guid() when attempting to set a group owner on a
file. This use is poorly supported by the rest of the code and should
be avoided.
Another thing to avoid is the (incorrect) assumption that because
NTSIDs are permitted to be variable length that the functions to deal
with their translation also expect variable length; while you are
permitted to ask about shorter ones, you have to provide for storage
of the largest possible one. Unless you are SMBFS or XSan, this
should not be an issue for you, but it is a potential place where
you'd write off the end of your memory during a copy/create operation
(C99 prohibits the use of a variant array at the end of a structure
embedded in a structure; gcc allows this if the first structure is at
the end of the second, rather than in the middle, but this is
technically a non-standard usage).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden