openwsman - core dump when using XPath filter with SfcbLocal frontend

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

openwsman - core dump when using XPath filter with SfcbLocal frontend

Zoltan Micskei
Hi,

(I'm using openwsman 2.3 (201203080941) and wsmancli 2.2.7.1 (201203081023) on CentOS 6.2 installed from the build.opensuse.org.)

When openwsmand is set to use the SfcbLocal frontend, the following query results in a core dump:

wsman -h localhost -u root -p password enumerate http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_KernelParameter
--dialect="http://www.w3.org/TR/1999/REC-xpath-19991116" --filter='../Linux_KernelParameter[Edittable="false"]'

(Note1: when using the XML frontend, the query results in a CannotProcessFilter fault with 'syntax error in query.')
(Note2: I'm not 100% sure whether the filter should be this, as I'm not aware of any WS-Management implementation that supports
Level 2 XPath filters, thus I could not try it.)
(Note3: The result is the same if --filter='foo' is used.)

The log of openwsmand is the following:

Mar 28 05:28:36 [31164] new cimclient: 0xb5805450
Mar 28 05:28:36 [31164] new cimclient: 1
Mar 28 05:28:36 [31164] no SelectorSet defined
Mar 28 05:28:36 [31164] method or action: Enumerate
Mar 28 05:28:36 [31164] method or action: Enumerate
--- syntax error, unexpected TOK_IDENTIFIER, expecting TOK_SELECT
--- from clause missing
Aborted (core dumped)

Looking at the error in gdb:
#0  0x00130424 in __kernel_vsyscall ()
#1  0x00360af1 in raise () from /lib/libc.so.6
#2  0x003623ca in abort () from /lib/libc.so.6
#3  0x00629219 in execQuery (mb=0xb6005450, cop=0xb60056a0, query=0xb6005310 "Edittable=false", lang=0x616ffb "WQL", rc=0xb6baae98)
    at cimcClientSfcbLocal.c:785
#4  0x006116f5 in cim_enum_instances (client=0xb6004018, enumInfo=0xb6003f88, status=0xb6baaf80)
    at /usr/src/debug/openwsman-2.3.0/src/plugins/cim/sfcc-interface.c:1182
#5  0x006164aa in CimResource_Enumerate_EP (cntx=0xb6003c70, enumInfo=0xb6003f88, status=0xb6baaf80, opaqueData=0x0)
    at /usr/src/debug/openwsman-2.3.0/src/plugins/cim/cim_data_stubs.c:443
...

The enumInfo contains the following data:
(gdb) print (WsEnumerateInfo) * enumInfo
$10 = {flags = 1048640, enumId = "7d050ffe-bc3a-1c3a-8002-8c3a19290c00", '\000' <repeats 27 times>, timeStamp = 0, expires = 0,
totalItems = 0,
  maxItems = 0, maxsize = 0, index = 0, enumResults = 0x0, pullResultPtr = 0x0, appEnumContext = 0x0, auth_data = {username =
0xb6004130 "meres",
    password = 0xb6004140 "LaborImage"}, releaseproc = 0x14b320 <CimResource_Release_EP>, epr_to = 0xb6004058
"http://localhost:5985/wsman",
  epr_uri = 0xb60040e8 "http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_KernelParameter", encoding = 0xb6002380 "UTF-8", aux =
0x0, epr = 0x0,
  filter = 0xb60052e0}

flags = 1048640 means WSMAN_ENUMINFO_POLY_INCLUDE | WSMAN_ENUMINFO_WQL, but this was an XPath query!


As far as I can see the problem is that openwsman accepts filters in the XPath dialect (see check_supported_dialect() in
wsman-dispatcher.c for WSM_XPATH_FILTER_DIALECT), but wsman_parse_enum_request() in wsman-soap-envelope.c handles it in the
following way:

...
                        else if(strcmp(filter->dialect, WSM_WQL_FILTER_DIALECT) == 0)
                                enumInfo->flags |= WSMAN_ENUMINFO_WQL;
                        else if(strcmp(filter->dialect, WSM_SELECTOR_FILTER_DIALECT) == 0)
                                enumInfo->flags |= WSMAN_ENUMINFO_SELECTOR;
                        else {
                                if(interpretxpath(&filter->query))
                                        enumInfo->flags |= WSMAN_ENUMINFO_WQL;
                                else
                                        return 0;

Thus in the else part the dialect is set to, which is wrong in my opinion. It should be set to XPath, but there is no appropriate
WSMAN_ENUMINFO_ for it. Moreover, checking of the XPath query is not implemented:

static int interpretxpath(char **xpath)
{
        return 1;
}


Suggestions:
1. Setting the WSMAN_ENUMINFO_WQL flag at line 591 of wsman-soap-envelope.c is wrong, maybe a WSMAN_ENUMINFO_XPATH can be introduced
in wsman-soap.h, and that flag can be used here. In this case at least the query would not result in a core dump, 'just' result in a
simple, full enumeration.
2. Maybe a CannotProcessFilter fault could be returned in this case to alert the user that XPath filters are not supported.

Regards,
Zoltan Micskei


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openwsman - core dump when using XPath filter with SfcbLocal frontend

Klaus Kaempf
Hi Zoltan,

great catch and analysis, thanks !

[...]

>
> As far as I can see the problem is that openwsman accepts filters in the XPath dialect (see check_supported_dialect() in
> wsman-dispatcher.c for WSM_XPATH_FILTER_DIALECT), but wsman_parse_enum_request() in wsman-soap-envelope.c handles it in the
> following way:
>
> ...
> else if(strcmp(filter->dialect, WSM_WQL_FILTER_DIALECT) == 0)
> enumInfo->flags |= WSMAN_ENUMINFO_WQL;
> else if(strcmp(filter->dialect, WSM_SELECTOR_FILTER_DIALECT) == 0)
> enumInfo->flags |= WSMAN_ENUMINFO_SELECTOR;
> else {
> if(interpretxpath(&filter->query))
> enumInfo->flags |= WSMAN_ENUMINFO_WQL;
> else
> return 0;
>
> Thus in the else part the dialect is set to, which is wrong in my opinion. It should be set to XPath, but there is no appropriate
> WSMAN_ENUMINFO_ for it.

Right. The above code implements lines 3238/3239 of DSP0226 (v 1.1.0)
which defines the default filter dialect as XPath.

Flagging an unrecognized filter dialect as 'WQL' is wrong.

> Moreover, checking of the XPath query is not implemented:
>
> static int interpretxpath(char **xpath)
> {
> return 1;
> }

Returning '1' here is definitely a bug.

>
>
> Suggestions:
> 1. Setting the WSMAN_ENUMINFO_WQL flag at line 591 of wsman-soap-envelope.c is wrong, maybe a WSMAN_ENUMINFO_XPATH can be introduced
> in wsman-soap.h, and that flag can be used here. In this case at least the query would not result in a core dump, 'just' result in a
> simple, full enumeration.

Agreed.

> 2. Maybe a CannotProcessFilter fault could be returned in this case to alert the user that XPath filters are not supported.

Yes.

I will push respective changes to git master.


Regards,

Klaus
---
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openwsman - core dump when using XPath filter with SfcbLocal frontend

Raveendra Reddy P
I am currently implementing a WSMAN client and am currently looking at implementing WSMAN Queries.

As of now I can see the support for WQL/CQL and standard selectors. But I am a bit confused on xpath support. I can see from winrm that the openwsman implementation supports xpath based transfer get.

However I keep on getting "Not supported" error on xpath based filtering on enumeration.

In the code (as I hit upon this thread) I see there is a code to stop support of xpath by returning 0 from interpretxpath()

So do I assume

a) Xpath is not supported in openwsman as of now. If not is there a plan in future to support this.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openwsman - core dump when using XPath filter with SfcbLocal frontend

Klaus Kaempf
* Raveendra Reddy P <[hidden email]> [Dec 18. 2013 10:39]:
> I am currently implementing a WSMAN client and am currently looking at
> implementing WSMAN Queries.
>
> As of now I can see the support for WQL/CQL and standard selectors.

This filter type is passed to the CIMOM, Openwsman does not try to
interprete such filters.

> But I am
> a bit confused on xpath support. I can see from winrm that the openwsman
> implementation supports xpath based transfer get.

Xpath is the default filter type according to the WS-Management
standard. However, Openwsman currently does not have an implementation
for this filter. I'd be happy to work with someone providing an
initial implementation.

Hth,

Klaus
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: openwsman - core dump when using XPath filter with SfcbLocal frontend

Raveendra Reddy P
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: openwsman - core dump when using XPath filter with SfcbLocal frontend

Klaus Kaempf
* Raveendra Reddy P <[hidden email]> [Dec 19. 2013 06:25]:
> Dell - Internal Use - Confidential
> Hello Klaus,
>
> Thanks for the clarification. sure we will look in to the xpath implementation in open source and let you know.
>

libxml2 - the underlying xml library for Openwsman - apparently
supports XPath, this could be a good start.

However, you should be aware that XPath filtering happens on the
Openwsman side. The CIMOM prepares the complete result, sends it to
Openwsman, and Openwsman then applies the filter.

This is different from wql/cql filtering which is usually done inside
the CIMOM (resp. inside the CIM provider). Therefore wql/cql filtering
is much better in terms of resource usage.

Klaus
--
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Openwsman-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openwsman-devel
Loading...