openwsman 2.2.0 uploaded !

[Klaus Kaempf]

Hi,

openwsman-2.2.0.tar.bz2 was just uploaded to the openwsman project at
sourceforge.

Before I make the public announcement on www.openwsman.org, I'd like
to give it some rest and ask everyone here for some testing.

Enjoy !

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

[Suresh Sundriyal-2]

Hi,

We just recently came across a weird problem in Openwsman-2.1.0 where Openwsman segfaults if a message is sent with a Content-Type header without a chartype. Looking at the code for Openwsman-2.2.0, I think this is going to affect Openwsman-2.2.0 as well. This is mostly because of get_request_encoding in wsmad-listener.c allowing encoding to be NULL and then letting that NULL propogate on without any checks. One instance that seems wrong is create_enum_info in wsman-soap.c, where msg->charset is u_strdup'ed without any check for NULL, which in turn calls memcpy on it without checking whether the pointer is NULL or not.

I believe I have a fix for this and it seems to be working with Openwsman-2.1.0 and behaving more or less like DSP0266 wants it to behave. :) I will check out the trunk tomorrow morning and create/send out a patch (it's getting kind of late in the night here).

--
Regards,
Suresh

________________________________________
From: Klaus Kaempf [kkaempf@...]
Sent: Tuesday, September 08, 2009 5:14 AM
To: openwsman-devel@...
Subject: [Openwsman-devel] openwsman 2.2.0 uploaded !

Hi,

openwsman-2.2.0.tar.bz2 was just uploaded to the openwsman project at
sourceforge.

Before I make the public announcement on www.openwsman.org, I'd like
to give it some rest and ask everyone here for some testing.

Enjoy !

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

[Suresh Sundriyal-2]

Hi Klaus,

I'm attaching the fix with the analysis:

The Problem:
============

If Openwsman receives an enumeration request with the Content-Type HTTP
header not containing the charset Openwsman segfaults.

The problem seems to occur because get_request_encoding method in
wsmand-listener.c, returns a NULL if charset is not found in the
Content-Type header. As a result of this the wsman_msg->charset is set
to NULL in the server_callback method in the same file. When the code
reaches create_enum_info in the wsman-soap.c file, it tries to u_strdup
the NULL wsman_msg->charset, which in turn tries to memcpy the NULL
pointer, leading to a segfault.

Solutions:
==========

I've been looking at the HTTP specs and the WS-Management specs and by
now I can come up with at least three ways to handle the problem. I'll
explain all of them but sending am the fix  that I think is the most
suitable.

1. The HTTP spec is quite vague about the charset field in the
Content-Type (or at least  I can't seem to wrap my head around it). I
did however get the bright idea of sending back one of the appropriate
4xx errors. However, those errors are quite vague themselves and I don't
find this approach very user friendly. I think I can whip up something
for this approach if that is what you want to go with.

2. Looking at DSP0266, the section R13.1-5, is very similar to this case
except that it deals with the actual encoding of the SOAP document and
not the HTTP header and suggests returning EncodingLimit fault with
CharacterSet fault detail. However, as I pointed out earlier, this deals
with the actual SOAP-XML encoding and not the HTTP header. One could
argue that not finding the actual encoding of the request on the wire is
as good as not being able to find the encoding of the enclosed message.
I do have a changeset that implements this fix, let me know if this is
the approach that you wish to take and I will mail that in.

3. Finally I stumbled upon
http://www.w3.org/International/O-HTTP-charset
This tutorial about charset mentioned that if the charset was missing,
the browsers usually use a user's default preferences to display the
message. If not, according to the document, HTTP specifies ISO-8859-1 as
the default encoding however goes on to suggest that UTF-8 is a good
default option.

Even though Openwsman does not have a default encoding, LibXML2 does
fall back to UTF-8 by default, I think. So I think it would make sense
for us to fall back on UTF-8 by default. The patch that I am sending
sets encoding to UTF-8 if the HTTP Content-Type header does not specify
the charset. This also happens  to be the simplest of the fix. :)


Let me know which one of the options you wish to go with or if there are
any other suggestions.

--
Regards,
Suresh

Suresh Sundriyal wrote:

> Hi,
>
> We just recently came across a weird problem in Openwsman-2.1.0 where Openwsman segfaults if a message is sent with a Content-Type header without a chartype. Looking at the code for Openwsman-2.2.0, I think this is going to affect Openwsman-2.2.0 as well. This is mostly because of get_request_encoding in wsmad-listener.c allowing encoding to be NULL and then letting that NULL propogate on without any checks. One instance that seems wrong is create_enum_info in wsman-soap.c, where msg->charset is u_strdup'ed without any check for NULL, which in turn calls memcpy on it without checking whether the pointer is NULL or not.
>
> I believe I have a fix for this and it seems to be working with Openwsman-2.1.0 and behaving more or less like DSP0266 wants it to behave. :) I will check out the trunk tomorrow morning and create/send out a patch (it's getting kind of late in the night here).
>
> --
> Regards,
> Suresh
>
> ________________________________________
> From: Klaus Kaempf [kkaempf@...]
> Sent: Tuesday, September 08, 2009 5:14 AM
> To: openwsman-devel@...
> Subject: [Openwsman-devel] openwsman 2.2.0 uploaded !
>
> Hi,
>
> openwsman-2.2.0.tar.bz2 was just uploaded to the openwsman project at
> sourceforge.
>
> Before I make the public announcement on www.openwsman.org, I'd like
> to give it some rest and ask everyone here for some testing.
>
> Enjoy !
>
> Klaus
> ---
> SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Openwsman-devel mailing list
> Openwsman-devel@...
> https://lists.sourceforge.net/lists/listinfo/openwsman-devel

Index: src/server/wsmand-listener.c
===================================================================
--- src/server/wsmand-listener.c (revision 3250)
+++ src/server/wsmand-listener.c (working copy)
@@ -127,7 +127,7 @@
 char *get_request_encoding(struct shttpd_arg *arg) {
  const char *content_type;
  char *p;
- char *encoding = NULL;
+ char *encoding = "UTF-8";
 
  content_type = shttpd_get_header(arg, "Content-Type");
  if(content_type ) {

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel

[Klaus Kaempf]

* Suresh Sundriyal <ssundriy@...> [Sep 09. 2009 23:34]:
> Hi Klaus,
>
> I'm attaching the fix with the analysis:

Thanks for finding and fixing the bug. And special thanks for your
exhaustive analysis.

I applied the fix (modulo some code cleanups) to svn head as rev 3251.

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Openwsman-devel mailing list
Openwsman-devel@...
https://lists.sourceforge.net/lists/listinfo/openwsman-devel