Re: ACL handling for NFSv4
Re: ACL handling for NFSv4
- Subject: Re: ACL handling for NFSv4
- From: Terry Lambert <email@hidden>
- Date: Mon, 1 Dec 2008 16:27:14 -0800
On Nov 27, 2008, at 11:39 PM, Michael Smith wrote:
On Nov 27, 2008, at 9:06 AM, Rick Macklem wrote:
From looking at kern_credential.c, all I can think of is doing
kauth_cred_guid2gid() first and assuming it is a group, if it
succeeds.
(Which won't work if a given guid_t represents both a gid and uid.)
Any suggestions on how to handle this?
GUIDs are globally unique IDs; it is a directory service
administration error to have a GUID that maps to more than one entity.
Group first is a sensible policy; it's reasonable to expect that ACL
entries will tend to indirect through role groups than directly
reference users.
I agree with this, but you need to be very careful here.
A lot of client/server enforcement is predicated on the idea that the
client and server will be members of the same security association,
and being members of the same SA, you will get the same answer for
both ends. In most of these cases, the enforcement is intended to be
done server-side, while (potentially) being originated client-side or
via inheritance.
For GUID translations for unknown GUIDs, which are "unknown" because
you have disconnected your laptop from the corporate network and
happened to be using ACLs on it, or you have disconnected your laptop
from one of maybe three SAs it's normally a member of (e.g. you are in
your home office talking to your home office server(SA 1), your
Internet connection is up(SA 2), but your VPN connection into work is
currently down(SA 3)), then DS will make up a transient answer for you.
This will boil down to you being likely to get an answer to the first
question you ask in this situation, i.e. "please give me a transient
GID for this GUID" or "please give me a transient UID for this GUID",
but not both.
Mike's right about what the default ask order should probably be in
this situation, since it's the most probable mapping, and anyone who
is thinking it is probably right about "I should never run my network
this way in the first place".
-- 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