From sacadmin Tue Oct 23 16:52:24 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9NNqOHj026053; Tue, 23 Oct 2007 16:52:24 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9NNqOhC026049; Tue, 23 Oct 2007 16:52:24 -0700 (PDT) Date: Tue, 23 Oct 2007 16:52:24 -0700 (PDT) From: Gary Winiger Message-Id: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com, psarc-ext@sun.com Cc: david.maxera@sun.com, winchester@sun.com Subject: 2007/616 - Winchester update for diagonal ID mapping Status: RO Content-Length: 6778 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@ unixuser:root The "winuser" and "wingroup" id selectors are now significant: the rule applies only if Administrators@ is a group. Whether Administrators@ 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. From gww@sac.sfbay.sun.com Tue Oct 23 16:52:32 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9NNqVun026067 for ; Tue, 23 Oct 2007 16:52:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9NNn2Qm024380; Wed, 24 Oct 2007 00:49:03 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQE0040925PXO00@brm-avmta-1.central.sun.com>; Tue, 23 Oct 2007 17:49:01 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQE00J1K25O7Q70@brm-avmta-1.central.sun.com>; Tue, 23 Oct 2007 17:49:00 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9NNmx1b052037; Tue, 23 Oct 2007 16:48:59 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9NNqOHj026053; Tue, 23 Oct 2007 16:52:24 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9NNqOhC026049; Tue, 23 Oct 2007 16:52:24 -0700 (PDT) Date: Tue, 23 Oct 2007 16:52:24 -0700 (PDT) From: Gary Winiger Subject: 2007/616 - Winchester update for diagonal ID mapping To: PSARC-record@sac.sfbay.sun.com, psarc-ext@sun.com Cc: david.maxera@sun.com, winchester@sun.com Message-id: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6778 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@ unixuser:root The "winuser" and "wingroup" id selectors are now significant: the rule applies only if Administrators@ is a group. Whether Administrators@ 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. From Darren.Moffat@sun.com Thu Oct 25 03:27:57 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9PARu9w014190 for ; Thu, 25 Oct 2007 03:27:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9PAOQL4004224; Thu, 25 Oct 2007 11:24:28 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQG0020LQ8PHZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Oct 2007 03:24:25 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQG00BVYQ8OO080@nwk-avmta-1.sfbay.Sun.COM>; Thu, 25 Oct 2007 03:24:24 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9PAONZ4008994; Thu, 25 Oct 2007 10:24:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQG00301O2BJ500@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 25 Oct 2007 11:24:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQG00K74Q8FHL10@fe-emea-10.sun.com>; Thu, 25 Oct 2007 11:24:16 +0100 (BST) Date: Thu, 25 Oct 2007 11:24:15 +0100 From: Darren J Moffat Subject: Re: 2007/616 - Winchester update for diagonal ID mapping In-reply-to: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-record@sac.sfbay.sun.com, psarc-ext@sun.com, David.Maxera@sun.com, winchester@sun.com Message-id: <47206ECF.2070901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 947 Gary Winiger wrote: > 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. I don't see any issues in this case, for me it read as borderline closed approved automatic given that CIFS hasn't integrated yet. As an aside I personally prefer the Windows model that file owners can be a group rather than the POSIX model and it is good to see that we can now support this for CIFS. -- Darren J Moffat From sacadmin Thu Oct 25 03:27:58 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9PARwMo014194; Thu, 25 Oct 2007 03:27:58 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9PAOT0H024531; Thu, 25 Oct 2007 03:24:29 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9PAONxJ008993; Thu, 25 Oct 2007 10:24:23 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQG00301O2BJ500@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 25 Oct 2007 11:24:23 +0100 (BST) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQG00K74Q8FHL10@fe-emea-10.sun.com>; Thu, 25 Oct 2007 11:24:16 +0100 (BST) Date: Thu, 25 Oct 2007 11:24:15 +0100 From: Darren J Moffat Subject: Re: 2007/616 - Winchester update for diagonal ID mapping In-reply-to: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: PSARC-record@sac.sfbay.sun.com, psarc-ext@Sun.COM, David.Maxera@Sun.COM, winchester@Sun.COM Message-id: <47206ECF.2070901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200710232352.l9NNqOhC026049@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 947 Gary Winiger wrote: > 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. I don't see any issues in this case, for me it read as borderline closed approved automatic given that CIFS hasn't integrated yet. As an aside I personally prefer the Windows model that file owners can be a group rather than the POSIX model and it is good to see that we can now support this for CIFS. -- Darren J Moffat From gww@eng.sun.com Sat Oct 27 11:03:02 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9RI328Z010741 for ; Sat, 27 Oct 2007 11:03:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9RHxWvQ007835; Sat, 27 Oct 2007 10:59:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQL00H030N8P800@nwk-avmta-2.sfbay.sun.com>; Sat, 27 Oct 2007 10:59:32 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQL007YE0N8YXB0@nwk-avmta-2.sfbay.sun.com>; Sat, 27 Oct 2007 10:59:32 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9RHxVxf060659; Sat, 27 Oct 2007 10:59:31 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l9RI1rag006343; Sat, 27 Oct 2007 11:01:53 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l9RI1rcS006342; Sat, 27 Oct 2007 11:01:53 -0700 (PDT) Date: Sat, 27 Oct 2007 11:01:53 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/616 - Winchester update for diagonal ID mapping To: gww@sac.sfbay.sun.com, psarc-ext@sun.com Cc: david.maxera@sun.com, winchester@sun.com Message-id: <200710271801.l9RI1rcS006342@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 341 > 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. There being no outstanding issues and the timer having expired, I'm (belatedly) marking this case approved. Gary..