On Tue, Mar 31, 2009 at 02:00:48PM -0700, Matthew Ahrens wrote:
> Nicolas Williams wrote:
> >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?
I said so myself: using getpwnam()/getgrnam() here means relying on
nsswitch.conf being configured to use nss_ad. That's not user
friendly...
It's arguably more correct from one p.o.v., and arguably less correct
from another.
> >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()
This algorithm seems unfortunate. I'd rather that nss_ad always be
configured in nsswitch.conf and only be active if AD is in use.
Actually, nss_ad should probably be generalized to be less AD-specific.
Think of Administrator at localhost and Guest User at localhost in workgroup
mode, as well as of cross-Unix domain ID mapping.
Because I doubt nss_ad will be generalized, or that it will always be
configured in nsswitch.conf, I think it's too soon to actually establish
a rule that system software should prefer getXbyYs over ID mapping APIs.
But it does seem like a good _future_ rule. I commented mostly because
I wanted future ARCheologists to find something in the case record about
this.
> 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.
Yup.
> 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.
Yup.
> >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.
Right now I don't. Thus I think this sub-thread should end here :) at
least as far as the ARC case record goes.
Thanks!
Nico
--
