From sacadmin Thu Jun 26 20:21:59 2008 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 m5R3Lxj9014238; Thu, 26 Jun 2008 20:21:59 -0700 (PDT) Received: (from nw141292@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5R3LxT2014234; Thu, 26 Jun 2008 20:21:59 -0700 (PDT) Date: Thu, 26 Jun 2008 20:21:59 -0700 (PDT) From: Nicolas Williams Message-Id: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Afshin.Ardakani@Sun.COM, Nicolas.Williams@Sun.COM Subject: Unresolvable SID mapping [PSARC/2008/408 Self Review] Status: RO Content-Length: 2268 I'm sponsoring this self-approved case on behalf of the ID mapping i-team. BACKGROUND ---------- PSARC/2006/315 introduced an ID mapping service (svc:/system/idmap) for Solaris that maps between Windows users and groups (identified by names and "SIDs") and POSIX users and groups (identified by names and UIDs/GIDs). The idmap service only maps Windows entities that can be resolved (i.e., names that can be resolved to SIDs and vice-versa). This means that only users/groups which exist in a Windows domain can be referenced in file security descriptors (file owner, group and ACL). Contrast this to POSIX IDs: chown(2), acl(2), facl(2) don't reject UIDs and GIDs that cannot be resolved through Unix name services. PROBLEM ------- However, there are at least two cases where we need to be able to store SIDs in file ACL entries (and as file owner/group) where the SID cannot be resolved to a name at all. Such SIDs can generally not appear in any cred_t, therefore ACL entries referencing them have no effect. The two known use cases are: a) Microsoft SQL Server, which creates files with ACL entries that reference SIDs local to the system on which SQL Server runs, and b) data migration, where it is common-place to copy files first, then later change the SIDs referenced in their ACLs. (a) is a pressing business issue. Note that simply assigning ephemeral IDs to any unresolvable SID referenced by a CIFS client allows for a denial of service (DoS) attack where a client consumes all available ephemeral IDs (they number slightly fewer than 2^31 UIDs and GIDs). We will pursue a long-term solution that does not enable such a DoS. In the meantime we propose a temporary, undocumented solution to enable ephemeral ID mapping of unresolvable SIDs. PROPOSAL -------- Add a private property, config/map_unresolvable_sids, to the idmap service which, when it exists, allows the service to perform ephemeral ID mapping for unresolvable SIDs. This feature and associated service property will be removed when a long-term solution to the problem that does not create a DoS is implemented. An early version of one proposal for a long-term solution can be found in the comments for: 6718001 stop-gap needed: ephemeral ID mapping for non-resolvable SIDs From sacadmin Thu Jun 26 20:26:24 2008 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 m5R3QNmK014272 for ; Thu, 26 Jun 2008 20:26:23 -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.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5R3QBsT025110; Fri, 27 Jun 2008 04:26:19 +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 <0K3300109QVTFD00@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 21:26:17 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3300A98QVTLB70@brm-avmta-1.central.sun.com>; Thu, 26 Jun 2008 21:26:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5R3QGoI003856; Thu, 26 Jun 2008 22:26:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5R3QGAt003855; Thu, 26 Jun 2008 22:26:16 -0500 (CDT) Date: Thu, 26 Jun 2008 22:26:16 -0500 From: Nicolas Williams Subject: Re: Unresolvable SID mapping [PSARC/2008/408 Self Review] In-reply-to: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> To: PSARC@sun.com, Afshin.Ardakani@sun.com Cc: Nicolas.Williams@sun.com Mail-followup-to: PSARC@sun.com, Afshin.Ardakani@Sun.COM Message-id: <20080627032616.GJ2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 501 After sending this out, it occurred to me that this is probably not self-approved material without at least an explanation of why a temporary solution is so important. The business issue is that this problem must be addressed by snv_95 as that is the last build in which features from ONNV will be pulled into the Amber Road storage appliance. Otherwise we would pursue only the long-term solution. I'm happy to make this a fasttrack too if anyone objects to self-approval for this case. Nico -- From sacadmin Fri Jun 27 04:28:53 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5RBSrDg026540; Fri, 27 Jun 2008 04:28:53 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5RBSqaw057324; Fri, 27 Jun 2008 04:28:53 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5RBSlAj025610; Fri, 27 Jun 2008 11:28:47 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 <0K3400J017OPOP00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 27 Jun 2008 12:28:47 +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 <0K3400GRFD7PNA90@fe-emea-10.sun.com>; Fri, 27 Jun 2008 12:28:40 +0100 (BST) Date: Fri, 27 Jun 2008 12:28:37 +0100 From: Darren J Moffat Subject: Re: Unresolvable SID mapping [PSARC/2008/408 Self Review] In-reply-to: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Nicolas Williams Cc: PSARC@sac.sfbay.sun.com, Afshin.Ardakani@Sun.COM, Nicolas.Williams@Sun.COM Message-id: <4864CEE5.60704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 547 Nicolas Williams wrote: > Add a private property, config/map_unresolvable_sids, to the idmap > service which, when it exists, allows the service to perform ephemeral > ID mapping for unresolvable SIDs. > > This feature and associated service property will be removed when a > long-term solution to the problem that does not create a DoS is > implemented. Tiny tiny nit, given the intended short term nature of this it might be worth naming it as config/private_map_unresolvable_sids. I'm happy with the case as is though. -- Darren J Moffat From sacadmin Fri Jun 27 09:03:55 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5RG3s7Z004091; Fri, 27 Jun 2008 09:03:55 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5RG3sXw004230; Fri, 27 Jun 2008 11:03:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5RG3sar004229; Fri, 27 Jun 2008 11:03:54 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 27 Jun 2008 11:03:54 -0500 From: Nicolas Williams To: Darren J Moffat Cc: Nicolas Williams , PSARC@sac.sfbay.sun.com, Afshin.Ardakani@sun.com Subject: Re: Unresolvable SID mapping [PSARC/2008/408 Self Review] Message-ID: <20080627160353.GO2735@Sun.COM> Mail-Followup-To: Darren J Moffat , Nicolas Williams , PSARC@sac.sfbay.sun.com, Afshin.Ardakani@Sun.COM References: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> <4864CEE5.60704@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4864CEE5.60704@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 960 On Fri, Jun 27, 2008 at 12:28:37PM +0100, Darren J Moffat wrote: > Nicolas Williams wrote: > >Add a private property, config/map_unresolvable_sids, to the idmap > >service which, when it exists, allows the service to perform ephemeral > >ID mapping for unresolvable SIDs. > > > >This feature and associated service property will be removed when a > >long-term solution to the problem that does not create a DoS is > >implemented. > > Tiny tiny nit, given the intended short term nature of this it might be > worth naming it as config/private_map_unresolvable_sids. As it is most of the service's existing properties are private and undocumented, but most are also permanent in that they'll be committed once we find a good home for them. I don't want folks browsing through the source to get confused as to the stability of this property versus the other private properties, otherwise I'd agree. > I'm happy with the case as is though. Thanks, Nico -- From sacadmin Fri Jun 27 09:06:36 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5RG6aYl004241; Fri, 27 Jun 2008 09:06:36 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5RG6awg022572; Fri, 27 Jun 2008 09:06:36 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m5RG6UT2008070; Fri, 27 Jun 2008 16:06:30 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K3400601OHAU800@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 27 Jun 2008 17:06:30 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K3400MU1Q2F5KA0@fe-emea-09.sun.com>; Fri, 27 Jun 2008 17:06:16 +0100 (BST) Date: Fri, 27 Jun 2008 17:06:15 +0100 From: Darren J Moffat Subject: Re: Unresolvable SID mapping [PSARC/2008/408 Self Review] In-reply-to: <20080627160353.GO2735@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Darren J Moffat , Nicolas Williams , PSARC@sac.sfbay.sun.com, Afshin.Ardakani@Sun.COM Message-id: <48650FF7.7070004@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200806270321.m5R3LxT2014234@sac.sfbay.sun.com> <4864CEE5.60704@Sun.COM> <20080627160353.GO2735@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 1034 Nicolas Williams wrote: > On Fri, Jun 27, 2008 at 12:28:37PM +0100, Darren J Moffat wrote: >> Nicolas Williams wrote: >>> Add a private property, config/map_unresolvable_sids, to the idmap >>> service which, when it exists, allows the service to perform ephemeral >>> ID mapping for unresolvable SIDs. >>> >>> This feature and associated service property will be removed when a >>> long-term solution to the problem that does not create a DoS is >>> implemented. >> Tiny tiny nit, given the intended short term nature of this it might be >> worth naming it as config/private_map_unresolvable_sids. > > As it is most of the service's existing properties are private and > undocumented, but most are also permanent in that they'll be committed > once we find a good home for them. > > I don't want folks browsing through the source to get confused as to the > stability of this property versus the other private properties, > otherwise I'd agree. Makes perfect sense. I'm happy to leave the case as specified. -- Darren J Moffat