Re: ACL handling for NFSv4
Re: ACL handling for NFSv4
- Subject: Re: ACL handling for NFSv4
- From: Rick Macklem <email@hidden>
- Date: Fri, 14 Nov 2008 15:23:06 -0500 (EST)
On Fri, 14 Nov 2008, Quinn wrote:
At 15:38 -0500 13/11/08, Rick Macklem wrote:
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?
<sys/kauth.h> has KPIs to map from GUIDs to UID/GID (kauth_cred_guid2uid,
kauth_cred_guid2gid) and vice versa (kauth_cred_uid2guid,
kauth_cred_gid2guid). While I'm not an NFSv4 expert, so I really have no
idea whether this is the right thing to do, I suspect you might find them
useful (-:
Yes, that does look like it'll be useful. Thanks a lot. (I now see that it
checks a cache and calls a userland daemon upon a miss. I also see that
dsmemberutil(1) knows how to figure these out based upon a user or group.)
As an aside, NFSv4 ACLs look just like NT4 ACLs, which appear to look just
like Leopard ACLs, so the only trick seems to be mapping the "who" (called
ace_applicable on Leopard). It looks like the above, plus
kauth_wellknown_guid() will do that. (I haven't found an inverse function
to kauth_wellknown_guid() that creates one, but I can easily make one up.)
In NFSv4, ACLs are checked/enforced by the server, so I don't see that as
an issue for the client.
So, the Get ACL case looks ok, but that still leaves the Set ACL case as
a bit of an issue. It looks to me that it is always done via
vnode_set_filesec() which ends up doing a VNOP_SETXATTR() for the filesec.
Which finally gets me to the questions:
Can I get away with ignoring the fsec_owner and fsec_group fields,
since I have no way of storing them on the server?
Does setting these imply a change in file ownership?
If anyone happens to have answers to these, thanks in advance for them,
but in any case, with Quinn's help, it looks like I can at least Get ACLs
ok. (Great, I like it:-)
Thanks again, rick
_______________________________________________
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