Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 08:39:05PM -0700, Matthew Ahrens wrote:
>> The <user> or <group> is specified using one of the following forms:
>> posix name (eg. ahrens)
>> posix numeric id (eg. 126829)
>> sid name (eg. ahrens at sun)
>> sid numeric id (eg. S-1-12345-12423-125829)
>
> It's worth noting that the third user/group form ("sid name") could be
> resolved either via getpwnam(3C)/getgrnam(3C) or by using ID mapping
> APIs. The former requires that nss_ad(5) be used as a backend for
> passwd and group in nsswitch.conf(4), which makes it somewhat not
> friendly.
>
> In spite of this ISTM that using getpwnam(3C)/getgrnam(3C) is arguably
> more correct. Yes, any resulting ephemeral UIDs/GIDs have to then be
> mapped back to SIDs via ID mapping APIs,
But if the system has not been configured in that way (using nss_ad), then
this getpwnam() would simply fail, which doesn't seem very useful. Unless
I'm misunderstanding. How would getpwnam() return an ephemeral UID? Does it
fake up a struct passwd entry? Does it do that if you don't use nss_ad?
The goal here is to implement a symmetric user interface:
"zfs userspace" tells you the actual sid name (or domain+rid with -n) that is
being charged (computed from the ZFS FUID). The user should be able to set
quotas on that value with "zfs set
userquota@<thing-from-zfs-userspace>=<quota>".
I suppose you could argue that if they didn't set up nss_ad, then we should
not be able to map the domain+rid to a sid name, so they would only see
domain+rid, and be able to set quotas using that same domain+rid. But it
doesn't seem very helpful to make the user run idmap(1m) to do the mapping
themself.
> but presumably this happens in
> the "posix numeric id" ID case too if the given ID is an ephemeral ID
> (or is that not allowed? and if so, why?).
Yes, this is done by idmap_get_sidby[ug]id().
> The issue: how should system components resolve name at domain user/group
> name forms? Via getXbyname()? Or via Solaris ID mapping APIs?
Indeed. It would be great to have one library function to resolve <string
user identifier> -> S-1-numeric-domain + rid. (With a NULL domain in the
case that it's a POSIX id.) In the absence of that, the current algorithm is:
if there's an '@' in the name:
sid_to_id()
idmap_get_sidby[ug]id()
else:
getpwnam()/getgrnam()
Note that in the '@' case, we are translating from user at domain -> (possibly
ephemeral) UID -> S-1-numeric-domain + rid. This is pretty roundabout, so we
have filed RFE 6816841 to provide a more direct interface to map user at domain
-> S-1-numeric-domain + rid.
Similarly, when printing SIDs from "zfs userspace, we translate from
S-1-numeric-domain + rid to user at domain by doing sid_to_id() and then
idmap_getwinnameby[ug]id(). The new interfaces provided by 6816841 will
simplify this.
> I'm not sure this matters much for now. I doubt there's much use of '@'
> in user/group names outside the context of nss_ad/ID mapping. And I
> believe any future cross-Unix domain ID mapping ought to fit into the
> existing Solaris ID mapping framework, so that using existing Solaris ID
> mapping APIs should be future-proof.
Indeed, it would be great if that functionality was available. If you have
suggestions on how I could improve our algorithm using currently-available
interfaces, let me know.
--matt
