I'm sponsoring this fast track for David Maxera. It proposes
to update the Winchester ID mapping service to resolve an
incompatibility between the POSIX and Windows views of users
and groups.
The idmap(1M) interface taxonomy remains unchanged as Uncommitted.
This case requests a Patch release binding which is compatible
with the Winchester release binding.
The project team indicated they are under some time pressure.
This seems straight forward to me, so I've set the timer for
3 days from now, Friday 26 Oct, 2007. As always more time
is granted if there are issues.
A full diffmk-ed man page is in the case directory.
Gary..
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BACKGROUND
==========
The idmap service (PSARC/2006/315 Winchester) provides mappings between
MS Windows identities (users and groups) and Solaris identities. These
identities are used to access files which, on both systems, have attributed
an owner and a group. There are fundamental differences between Windows
and Solaris types of identities which make the task challenging.
Solaris uses two different name spaces for users and groups. In other
words, we can have a user and a group with the same name and/or the same
numerical POSIX identifier (uid and gid). This is different from
Windows, which has a single name space for users and groups as well as for
their internal identifiers called security identifiers or SIDs. This
means that given a Windows name or SID, only the Windows naming service
can tell if it is a user or group.
PROBLEM
=======
It turns out that nothing on Windows prevents a group SID being a file
owner, and nothing prevents a user SID being a file group attribute. In
fact, Windows GUI itself uses certain groups like Administrators as a
file owner in many cases. Furthermore, any application can set the file
owner and group to whatever SID it likes. And MS even recommends this
in some cases.
PSARC/2006/715 CIFS Service needs to support this Windows behavior.
However, no mapping currently issued by the idmap service is suitable for
this purpose. idmap maps only Windows users to Solaris users and
Windows groups to Solaris groups. Solaris cannot use a group as a
file's owner or a user as a file's group.
PROPOSAL
========
This case proposes:
1) Introduce "diagonal" mappings, i.e., mappings of Windows groups to
Solaris users and Windows users to Solaris groups. These mappings
will be quite analogous to the ordinary mappings: there will be name
rules and ephemeral ids for them.
There will be no changes in the idmap(1M) syntax, only a change in
behavior. In the current version, an attempt to create a diagonal
mapping fails. After the proposed change, for example the following
command will be accepted:
idmap add wingroup:Administrators@<domain> unixuser:root
The "winuser" and "wingroup" id selectors are now significant: the
rule applies only if Administrators@<domain> is a group. Whether
Administrators@<domain> is a group will be evaluated when a mapping
is required, not when the rule is created.
2) This project does not change the libidmap API related to the mappings
(which have been contracted to the CIFS server project).
Functions like idmap_get_uidbysid() will simply return the diagonal
mapping in the situation whereas they currently fail with
IDMAP_ERR_NOTUSER or IDMAP_ERR_NOTGROUP. The idmap_get_pidbysid()
function will return a UID or a GID according to the type of entity
that the input SID represents.
This project makes some changes to the libidmap API related to its
administrative interface, but this part of the API has not been
contracted.
3) The kidmap API parallels the libidmap interfaces, except that it
doesn't include the administrative interface. Therefore, it needs no
changes (see (2) above).
4) The schema for /var/idmap/idmap.db changes incompatibly. idmapd
will be automatically detect and upgrade the schema of this
persistent database, thus avoiding any upgrade issues.
5) The Samba and NetApp usermap.cfg formats don't support diagonal
mappings, so the export to these formats will skip them. There is no
way to encode the diagonal mappings in these formats.
idmap(1M)
=========
Mapping Mechanisms
The idmapd(1M) daemon maps Windows user and group SIDs to
UNIX UIDs and GIDs as follows:
1. SIDs are mapped by name.
This mapping uses the name-based mapping rules that
are manually set up by the system administrator.
2. If no name-based mapping rule is found, the SID is
mapped to a dynamically allocated ephemeral ID.
This allocation uses the next available UID or GID
from 2^31 to 2^32 - 2.
Name-based mapping rules establish name equivalence between
Windows users and groups and their counterparts in the UNIX
name service. These rules persist across reboots.
The dynamic ID mappings are not retained across reboots. So,
any SIDs that are dynamically mapped to UNIX UIDs or GIDs
are most likely mapped to different IDs after rebooting the
system.
Note -
The idmapd daemon attempts to preserve ephemeral ID map-
pings across daemon restarts. However, when IDs cannot be
preserved, the daemon maps each previously mapped SID to a
new ephemeral UID or GID value. The daemon will never re-
use ephemeral UIDs or GIDs. If the idmapd daemon runs out
of ephemeral UIDs and GIDs, it returns an error as well as
a default UID or GID for SIDs that cannot be mapped by
name.
To prevent aliasing problems, all file systems, archive and
backup formats, and protocols must store SIDs or map all
UIDs and GIDs in the 2^31 to 2^32 - 2 range to the nobody
user and group.
+ It is possible to create also diagonal mappings. They are the
+ mappings between Windows groups and Solaris users and between
+ Solaris groups and Windows users. They are needed when Windows
+ uses a group identity as a file owner or vice versa.
Rule Lookup Order
When mapping a Windows name to a UNIX name, lookup for
name-based mapping rules is performed in the following
order:
Subcommands
The following subcommands are supported:
show [-c] name [target-type]
Shows the identity of type, target-type, that is mapped
| to the specified name. If the optional target-type is
+ omitted, the non-diagonal mapping is shown.
By default, this subcommand shows only mappings that
have been established already. The -c option forces the
evaluation of name-based mapping configurations or the
dynamic allocation of IDs.
