Issue 720: Object side-effect semantics (sec-rev) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: I am confused about semantics of the side-effecting override_default_* operations on CORBA::Objects. Are these overrides attached to the reference or to the destination? Resolution: resolved, close issue Revised Text: Actions taken: September 12, 1997: received issue March 26, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 12 Sep 1997 13:48:36 -0400 (EDT) From: Bob Scheifler - Sun Microsystems Reply-To: Bob Scheifler - Sun Microsystems Subject: question about Object side-effect semantics To: sec-rev@omg.org Content-MD5: RRo/9LgR2LEO1CBZg+vxzA== I'm confused about the semantics of the side-effecting override_default_* operations on Corba::Object. Are these overrides attached to the "reference" or to the "destination"? Specific example: A calls B, and passes a remote reference R1 B calls override_default_credentials on R1 A calls B, and passes a remote reference R2 (for the same object as R1) If B now uses R2 to make a call, are the override credentials used, or not? [If I should be sending this kind of question to sec-wg, please let me know.] Thanks. - Bob Return-Path: X-Sender: jeffm@visigenic.com Date: Fri, 12 Sep 1997 10:46:48 -0700 To: sec-rev@omg.org, issues@omg.org From: "Jeff Mischkinsky" Subject: Effect of mutability of obj refs Cc: Jishnu Mukerji The following interesting question has come in some discussion we are having. In the COSS Security spec, Corba::Object has been extended with side-effecting methods: void override_default_credentials ( in Credentials creds ); void override_default_QOP ( in Security::QOP qop ); void override_default_mechanism( in Security::MechanismType mechanism_type ); This appears to require that object references (IORs) become mutable. Assuming this to be so, what are the semantics when a client passes the same obj ref to an operation in two different paramaters. In one place the the CORBA spec says the semantics of aliased parameters is implementtion depdendent( 1.2.2 i think). However it seems like we should explicitly define the behavior in this case. The question is whether they are "shared" or not. If the are not shared, then overriding one of the paramaters does not affect the other. If they are shared, the effect of the override changes the "other" obj ref. thanks, jeff Jeff Mischkinsky email: jeffm@visigenic.com Senior Software Architect voice: +1(415)312-5158 Visigenic Software, Inc. fax: +1(415)286-2475 951 Mariner's Island Blvd. web: http://www.visigenic.com San Mateo, CA 94404 Return-Path: Sender: jis@fpk.hp.com Date: Fri, 12 Sep 1997 14:38:26 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Jeff Mischkinsky Cc: sec-rev@omg.org, issues@omg.org Subject: Re: Effect of mutability of obj refs References: <3.0.32.19970912104629.00988700@visigenic.com> Jeff Mischkinsky wrote: > > The following interesting question has come in some discussion we > are having. > > In the COSS Security spec, Corba::Object has been extended > with side-effecting methods: > > void override_default_credentials ( in Credentials creds ); > void override_default_QOP ( in Security::QOP qop ); > void override_default_mechanism( in Security::MechanismType > mechanism_type ); > > This appears to require that object references (IORs) become > mutable. Hmmm. Do I want to touch this one with a ten foot barge pole? Heck, why not - into the breach..... The IOR, i.e. the marshaled form of the object reference, does not need to be mutable, but the bound form needs to be. The IORs carry all the TAGs as they normally would. As we speak we are in the process of clarifying this in the Security spec by explcitly defining a (locality constrained) binding object associated with the bound object reference. > Assuming this to be so, what are the semantics when a client passes the > same obj ref to an operation in two different paramaters. In one place the > the CORBA spec says the semantics of aliased parameters is implementtion > depdendent( 1.2.2 i think). However it seems like we should explicitly > define the behavior in this case. When a client passes the object reference across an invocation of an operation of a "remote" object, it is just the IOR that is passed. The receiver of the object reference has to establish their own Credentials with the target object to use that object reference. They may obtain the sender's permission through some form of delegation. The notion of Credentials, and QOP are intimately associated with the particular location (i.e. process for a commonly obtained engineering concept). They do not leave the location (hence Credentials are location constrained etc.). These pieces of information (e.g. QOP, Credentials, mechanism) which constitute the Secure Association between a specific copy of the an object reference in a client and the target is encapsulated in the "binding" object associated with the object reference at the client end. None of the contents of the "binding" object is ever marshaled as a part of the IOR, though what the contents of the binding object can be is constrained by the contents of the IOR (e.g. an IOR that did not contain TAG_SPKM1_SEC_MECH cannot ever cause a "binding" to be setup with mechanism SPKM). The more interesting question, that Bob Kukura is researching, is the effect of the requirement that the binding associated with two copies of the same object reference in the same process can be different, since they can have different QOP and Credentials set on them. This has some interesting implementation consequences. We (Bobs Blakley and Kukura, myself and Richard Herbert will be discussing this issue among others in excrutiating detail bright and early on Sunday morning in Dublin. > The question is whether they are "shared" or not. If the are not shared, > then overriding one of the paramaters does not affect the other. If they > are shared, the effect of the override changes the "other" obj ref. Depends on what you mean by they. Hope the brief explanation clarifies more than confuses the audience. Regards, Jishnu. -- Jishnu Mukerji Systems Architect Open Systems Software Division Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA Return-Path: Sender: jis@fpk.hp.com Date: Fri, 12 Sep 1997 16:50:35 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Bob Scheifler - Sun Microsystems Cc: sec-rev@omg.org Subject: Re: question about Object side-effect semantics References: Bob Scheifler - Sun Microsystems wrote: > > I'm confused about the semantics of the side-effecting > override_default_* > operations on Corba::Object. Are these overrides attached to the > "reference" or to the "destination"? Specific example: > > A calls B, and passes a remote reference R1 > B calls override_default_credentials on R1 > A calls B, and passes a remote reference R2 (for the same object as > R1) > > If B now uses R2 to make a call, are the override credentials used, > or not? No. See lengthier explanation in my response to Jeff Mischkinsky's message. > [If I should be sending this kind of question to sec-wg, please let me know.] No, sec-wg is defunct. You could send it to secsig, but sending it to sec-rev is fine too. Jishnu -- Jishnu Mukerji Systems Architect Open Systems Software Division Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs Tel: +1 973 443 7528 MS D283, 180 Park Ave., Bldg. 103 Fax: +1 973 443 7602 Florham Park, NJ 07932-9998, USA