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 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?).
The issue: how should system components resolve name at domain user/group
name forms? Via getXbyname()? Or via Solaris ID mapping APIs?
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.
But just in case, and if nothing else for the benefit of future
ARCheologists, I'm only sending this comment to the case record.
Nico
--
