Issue 3912: How is an ORB to determine whether or not it is in an applet context? (java-rtf) Source: Improv Technologies (Dr. Mary Leland, ) Nature: Uncategorized Issue Severity: Summary: How is an ORB to determine whether or not it is in an applet context? The nearest that I can see is to check for the presence of a SecurityManager. If we are in an applet context, then there is a SecurityManager present, but the inverse (that the presence of a SecurityManager implies that we are in an applet) is not true. It is however the case that whenever a SecurityManager is present, potentially untrusted code is present, so the same constraints on the singleton ORB are probably appropriate. Therefore, I propose that the specification be changed to state that if System.getSecurityManager() returns a non-null result, the singeton ORB should be constrained to creating TypeCodes and Anys. Resolution: see below Revised Text: Replace the second paragraph under "Default Initialization" in Section 21.9.3 (bottom of page 129 in ptc/2000-07-03) with the following 2 paragraphs. They preserve the useful information about the Applet case, but make it clear that the singleton ORB returned by the no-argument ORB.init is constrained in any context. Replacement Text: "The primary use of the no-argument version of ORB.init() is to provide a factory for TypeCodes for use by Helper classes implementing the type() method, and to create Any instances that are used to describe union labels as part of creating a union TypeCode. In the case of an ORB within a browswer, these Helper classes may be baked-in to the browser (e.g., for the interface repository stubs or other wildly popular IDL) and so may be shared across untrusted applets downloaded into the browser. The returned ORB instance is shared across all applets and therefore must have sharply restricted capabilities so that unrelated applets can be isolated from each other. It is not intended to be used directly by applets." Actions taken: September 28, 2000: received issue February 27, 2001: closed issue Discussion: This is a re-submission of Issue 1751, which disappeared from the database without ever being actually resolved. End of Annotations:===== Date: Thu, 28 Sep 2000 13:19:19 -0400 From: Mary Leland Organization: HP EIAL X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, Java RTF Subject: How is an ORB to determine whether or not it is in an applet context? Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;^Ne9L^~e9:9@e9_(W!! This is a re-submission of Issue 1751, which disappeared from the database without ever being actually resolved. Original Text of Issue 1751: How is an ORB to determine whether or not it is in an applet context? The nearest that I can see is to check for the presence of a SecurityManager. If we are in an applet context, then there is a SecurityManager present, but the inverse (that the presence of a SecurityManager implies that we are in an applet) is not true. It is however the case that whenever a SecurityManager is present, potentially untrusted code is present, so the same constraints on the singleton ORB are probably appropriate. Therefore, I propose that the specification be changed to state that if System.getSecurityManager() returns a non-null result, the singeton ORB should be constrained to creating TypeCodes and Anys. Date: Thu, 28 Sep 2000 17:59:59 -0700 From: "Vijaykumar Natarajan" X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: java-rtf@emerald.omg.org Subject: Re: issue 3912 resubmission of issue 1751 -- Java RTF issue References: <4.2.0.58.20000928170217.00c68910@emerald.omg.org> Content-Type: multipart/mixed; boundary="------------E2FD3AF2E2D7F9C5F3864763" X-UIDL: 3;8e9^lN!!AoY!!_j(!! I am not sure I understand the issue here. First, when the ORB is in an applet context, it is initialized differently (using the ORB.init which takes the applet as parameter). Second, The singleton ORB is anyway constrained to produce only typecodes and anys. Am I missing any operations that are valid on the singleton, but do not deal w/ the creation of typecodes and anys? Vijay Juergen Boldt wrote: > This is issue # 3912 > > How is an ORB to determine whether or not it is in an applet >context? > > How is an ORB to determine whether or not it is in an applet >context? > The nearest that I can see is to check for the presence of > a SecurityManager. If we are in an applet context, then there is a > SecurityManager present, but the inverse (that the presence of a > SecurityManager implies that we are in an applet) is not true. > It is however the case that whenever a SecurityManager is present, > potentially untrusted code is present, so the same constraints on >the > singleton ORB are probably appropriate. > Therefore, I propose that the specification be changed to state > that if System.getSecurityManager() returns a non-null result, > the singeton ORB should be constrained to creating TypeCodes and >Anys. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > ================================================================ [] vijayn.vcf Date: Mon, 02 Oct 2000 14:27:25 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland CC: Java RTF Subject: Re: How is an ORB to determine whether or not it is in an applet context? References: <39D37D97.85ADC83A@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d$1!!EY_!!%]k!!pGmd9 Mary, I agree that it is not possible for the ORB returned by ORB.init() to determine that it is in an applet context. However, I believe a better resolution of this issue is to strike the reference to applet context altogether and say that the ORB returned by ORB.init() is a singleton ORB that is constrained to creating TypeCodes and Anys. This gives the singleton ORB consistent semantics across all calling contexts. Simon Mary Leland wrote: > > This is a re-submission of Issue 1751, which disappeared from > the database without ever being actually resolved. > > Original Text of Issue 1751: > How is an ORB to determine whether or not it is in an applet context? > The nearest that I can see is to check for the presence of > a SecurityManager. If we are in an applet context, then there is a > SecurityManager present, but the inverse (that the presence of a > SecurityManager implies that we are in an applet) is not true. > It is however the case that whenever a SecurityManager is present, > potentially untrusted code is present, so the same constraints on the > singleton ORB are probably appropriate. > Therefore, I propose that the specification be changed to state > that if System.getSecurityManager() returns a non-null result, > the singeton ORB should be constrained to creating TypeCodes and Anys. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 06 Oct 2000 14:13:17 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Cc: Java RTF Subject: Re: How is an ORB to determine whether or not it is in an applet context? References: <39D37D97.85ADC83A@fpk.hp.com> <39D88D3D.37210985@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: n&@!!'cNe9*%K!!H-od9 Simon & All, How about replacing the first paragraph under "Default Initialization" in Section 21.9.3 (bottom of page 129 in ptc/2000-07-03) with the following 2 paragraphs? They preserve the useful information about the Applet case, but make it clear that the singleton ORB returned by the no-argument ORB.init is constrained in any context. Replacement Text: "The only use of the no-argument version of ORB.init() is to provide a factory for TypeCodes for use by Helper classes implementing the type() method, and to create Any instances that are used to describe union labels as part of creating a union TypeCode. In the case of an ORB within a browswer, these Helper classes may be baked-in to the browser (e.g., for the interface repository stubs or other wildly popular IDL) and so may be shared across untrusted applets downloaded into the browser. The returned ORB instance is shared across all applets and therefore must have sharply restricted capabilities so that unrelated applets can be isolated from each other. It is not intended to be used directly by applets." Thanks, -- Mary Simon Nash wrote: > > Mary, > I agree that it is not possible for the ORB returned by ORB.init() to > determine that it is in an applet context. However, I believe a better > resolution of this issue is to strike the reference to applet context > altogether and say that the ORB returned by ORB.init() is a singleton > ORB that is constrained to creating TypeCodes and Anys. This gives the > singleton ORB consistent semantics across all calling contexts. > > Simon > > Mary Leland wrote: > > > > This is a re-submission of Issue 1751, which disappeared from > > the database without ever being actually resolved. > > > > Original Text of Issue 1751: > > How is an ORB to determine whether or not it is in an applet context? > > The nearest that I can see is to check for the presence of > > a SecurityManager. If we are in an applet context, then there is a > > SecurityManager present, but the inverse (that the presence of a > > SecurityManager implies that we are in an applet) is not true. > > It is however the case that whenever a SecurityManager is present, > > potentially untrusted code is present, so the same constraints on the > > singleton ORB are probably appropriate. > > Therefore, I propose that the specification be changed to state > > that if System.getSecurityManager() returns a non-null result, > > the singeton ORB should be constrained to creating TypeCodes and Anys. > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Sat, 07 Oct 2000 02:51:54 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland CC: Java RTF Subject: Re: How is an ORB to determine whether or not it is in an applet context? References: <39D37D97.85ADC83A@fpk.hp.com> <39D88D3D.37210985@hursley.ibm.com> <39DE163D.1234BE15@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $dc!!56@!!W*g!!UUQd9 Mary, 1. I think you meant to replace the second paragraph under "Default Initialization", not the first one. 2. I'm not comfortable with your change from "the primary use" to "the only use" (of the no-argument constructor). I thought the singleton ORB could create any TypeCode and any Any (no pun intended). Your change seems to imply that it would be OK for a compliant singleton ORB to only allow creating Anys that will be used as union labels within TypeCodes, assuming it could tell that this was their intended use. With these changes I would be OK with your proposal. Simon Mary Leland wrote: > > Simon & All, > > How about replacing the first paragraph under "Default Initialization" > in Section 21.9.3 (bottom of page 129 in ptc/2000-07-03) > with the following 2 paragraphs? They preserve the useful > information about the Applet case, but make it clear that > the singleton ORB returned by the no-argument ORB.init is > constrained in any context. > > Replacement Text: > > "The only use of the no-argument version of ORB.init() is to > provide a factory for TypeCodes for use by Helper classes > implementing the type() method, and to create Any instances > that are used to describe union labels as part of creating a > union TypeCode. > > In the case of an ORB within a browswer, these Helper classes > may be baked-in to the browser (e.g., for the interface > repository stubs or other wildly popular IDL) and so may be > shared across untrusted applets downloaded into the browser. > The returned ORB instance is shared across all applets and > therefore must have sharply restricted capabilities so that > unrelated applets can be isolated from each other. It is not > intended to be used directly by applets." > > Thanks, > -- Mary > > Simon Nash wrote: > > > > Mary, > > I agree that it is not possible for the ORB returned by ORB.init() to > > determine that it is in an applet context. However, I believe a better > > resolution of this issue is to strike the reference to applet context > > altogether and say that the ORB returned by ORB.init() is a singleton > > ORB that is constrained to creating TypeCodes and Anys. This gives the > > singleton ORB consistent semantics across all calling contexts. > > > > Simon > > > > Mary Leland wrote: > > > > > > This is a re-submission of Issue 1751, which disappeared from > > > the database without ever being actually resolved. > > > > > > Original Text of Issue 1751: > > > How is an ORB to determine whether or not it is in an applet context? > > > The nearest that I can see is to check for the presence of > > > a SecurityManager. If we are in an applet context, then there is a > > > SecurityManager present, but the inverse (that the presence of a > > > SecurityManager implies that we are in an applet) is not true. > > > It is however the case that whenever a SecurityManager is present, > > > potentially untrusted code is present, so the same constraints on the > > > singleton ORB are probably appropriate. > > > Therefore, I propose that the specification be changed to state > > > that if System.getSecurityManager() returns a non-null result, > > > the singeton ORB should be constrained to creating TypeCodes and Anys. > > > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Reply-To: From: "Nick Sharman" To: "Simon Nash" , "Mary Leland" Cc: "Java RTF" Subject: RE: How is an ORB to determine whether or not it is in an applet context? Date: Mon, 9 Oct 2000 15:28:51 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <39DE81BA.B0DCE776@hursley.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Mf@e9Q0O!!a\A!!/P7e9 Simon, > -----Original Message----- > From: Simon Nash [mailto:nash@hursley.ibm.com] > Sent: Saturday, October 07, 2000 2:52 AM > To: Mary Leland > Cc: Java RTF > Subject: Re: How is an ORB to determine whether or not it is in an > applet context? > > > Mary, > 1. I think you meant to replace the second paragraph under "Default > Initialization", not the first one. > > 2. I'm not comfortable with your change from "the primary use" to "the > only use" (of the no-argument constructor). > > I thought the singleton ORB could create any TypeCode and any Any > (no pun intended). Your change seems to imply that it would be OK for > a compliant singleton ORB to only allow creating Anys that will be > used as union labels within TypeCodes, assuming it could tell that this > was their intended use. Can Anys created by the singleton ORB hold useful object references? I think not; if you extract a stub from such an any, it won't be pointing to an ORB that will support invocations - you need a 'real' ORB for that. Or have I missed something obvious? > With these changes I would be OK with your proposal. > > Simon Regards Nick --------------------------------- Nick Sharman Architect, LiveContent BROKER Critical Path UK Tel: +44 (0) 161 333 4073 UK Fax: +44 (0) 161 333 4001 E-mail: mailto:nick.sharman@cp.net Web: http://www.cp.net