- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 26 Oct 2009 17:03:02 -0400
- To: Yves Lafon <ylafon@w3.org>
- Cc: Gilbert Pilz <gilbert.pilz@oracle.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OF16AA5E5E.66F296F8-ON8525765B.0072FAA7-8525765B.0073A31B@us.ibm.com>
I look at this slightly differently... you keep talking about how the Action and the Body MUST "match". To me that's actually not true - at least not the way you mean it. Sure from a human perspective there appears to be a relationship between the Action and the Body because they look similar, but in reality its just a coincidence. Back at the Redwood City F2F we talked about this, and we agreed that even if the spec said that the Action MUST be "Store" and the Body MUST be "Put" you'd still have an issue. And this is because the issue isn't that those two values needed to look alike, instead the issue is that the spec says what each one MUST be and if the client doesn't "match" what the spec says then its an error. So, if we did head down this path I wouldn't want any fault to talk about those values needing to match each other, I'd want it to talk about them not matching what the spec says they must be. thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com The more I'm around some people, the more I like my dog. Yves Lafon <ylafon@w3.org> Sent by: public-ws-resource-access-request@w3.org 10/26/2009 04:50 PM To Gilbert Pilz <gilbert.pilz@oracle.com> cc "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org> Subject Re: issue 7911 On Mon, 26 Oct 2009, Gilbert Pilz wrote: > Yves, > > I think we need to break your proposal down into its constituent pieces. > Firstly, there is the definition of the fault that is generated when/if an > implementation detects that the first child of the [Body] does not match the > [Action] property. I have two problems with this: > > F.1) What is the point of standardizing the definition of this fault? Since > the mismatch in question is a result of a coding error, it doesn't seem > reasonable to expect anyone to write client code that could detect this fault > and address the underlying problem in any meaningful way. It seems to me that > any SOAP fault with a code of soap11:Client/soap12:Sender and a > soap11:faultstring/soap12:Reason that is equivalent to "the first child of > the [Body] does not match the [Action] property" (properly translated of > course) would serve the same purpose. Ok, so malicious code wanting to exploit a buffer overflow using carafully crafted "wrong content" is a coding error? If you have an implementation that checks only the action property to check access and another one that checks only the body element to actually perform the request, then you have an issue. There is a difference between client requirements, currently in the spec (body MUST start with ... and action MUST be ...), and receiver requirements, especially in this case where we have two times the same information. Failing to explicitely check that on the receiving end leads to potential security issues. > F.2) Even if we stipulate that it is necessary to standardize the definition > of this fault, it's not clear to me that it's within the scope of the WS-RA > WG's charter to define what is, essentially, a general-purpose > SOAP/WS-Addressing fault. Ok, so why do we need a PutDenied fault? It's a generic ActionDenied fault that WS-Addressing should deal with, no? > Secondly, there is the requirement on all WS-T resource implementations to > check for this condition and generate the fault. > > R.1) Why only WS-T? WS-Enum, WS-Eventing, and WS-Mex all have unique [Body] > children. If it is important to check for this condition in WS-T, surely it > is also important to check for this condition in the other specs as well? > Even if we did modify your proposal to include WS-Enum, WS-Eventing, and > WS-Mex, from the perspective of a general SOAP/WS-* stack, it seems really > strange to perform this check just for these spec and not for any others > (i.e. WS-RM, WS-Trust, etc.) You are right, every time action is duplicated by a body element, it is needed. > R.2) For what it's worth, my developers don't want to implement this check. > It is not required for the correct implementation of the WS-T protocol (when > the client sent the invalid request we left the realm of what the protocol > defines) and, in their view, it is not likely to happen often enough to be > worth the runtime cost. > > *Counter Proposal*: Close With No Action > > - gp > > On 10/26/2009 6:15 AM, Yves Lafon wrote: >> On Thu, 22 Oct 2009, Gilbert Pilz wrote: >> >>> Just went to look at issue 7911 in the issues list and found a whole >>> discussion thread in the comments section. I might have missed the entire >>> thing if I didn't happen to stumble upon it. Could people please constrain >>> themselves to discussing issues on the mailing list and use the comments >>> section for major developments (i.e. new proposals, directional >>> resolutions, etc.)? >> >> You are entirely right, I should have moved discussion here... >> Here is my proposal for resolving that issue: >> >> In 3, before the definition of the different resource operations: >> >> "If the [Body] first child is not matching the >> [Action] parameter for any defined Resource Operation, the recipient MUST >> generate a ActionAndWrapperMismatch fault" >> >> and add the fault: >> << >> 5.4 ActionAndWrapperMismatch >> >> This fault is generated if the [Body] first child is not matching the >> [Action] >> >> [Code] s:Sender >> [Subcode] wst:ActionAndWrapperMismatch >> [Reason] Action and Wrapper mismatch >> [Detail] none >>>> >> >> >> > -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Monday, 26 October 2009 21:03:59 UTC