Devchandra L Meetei | 28 Oct 17:28 2014
Picon

Fwd: [VOTING RESULT] Bug 9903 - Remove the duplicate doc file and related cimcli doc from cimcli/doc

The proposed patch has been accepted
Yes vote: Deleisha
No Vote: None
Abstain vote: None
---------- Forwarded message ----------
From: Devchandra L Meetei <dlmeetei <at> gmail.com>
Date: Tue, Oct 21, 2014 at 8:30 PM
Subject: [VOTE] Bug 9903 - Remove the duplicate doc file and related cimcli doc from cimcli/doc
To: pegasus-architecture <pegasus-architecture <at> opengroup.org>


The proposed patch for bug 9903 is open for voting
http://bugzilla.openpegasus.org/show_bug.cgi?id=9903
Please register votes within 48 hours of initial acceptance period if possible.


--
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,” Steve Jobs



--
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,” Steve Jobs
Arunkumar | 9 Oct 00:58 2014
Picon

OpenPegasus cimserver UTF-8 issue in Windows 7 Russian

Hi,

I am just wondering if anyone has encountered any issue running 
OpenPegasus cimserver binary in Windows 7 Russian edition.

When I run cimserver in that OS, it throws an error saying that the config 
file is not in UTF-8 format, even though its in UTF-8 format.

Even OpenPegasus based CIM tools from HP and EMC are also having the same 
issue. 

Please let me know if I need to ensure any formatting and configuration 
for Windows 7 Russian. 

Thanks in advance.

Arun

Elliot Justice | 22 Sep 19:45 2014

Install duplicate DMTF schema

First some background.
We have clients using software on legacy servers that have OpenPegasus 
installed with versions ranging from 2.6 to 2.11 and we are planning to 
use OpenPegasus to augment one of our existing projects.We operating 
under the assumption that some of the clients may be using OP for some 
in house project. So for testability we would like to install a 
duplicate copy of the DMTF standard schema in a separate namespace so we 
can have some consistency for the project.

So far I've downloaded  and compiled the MOF files into a seperate 
namespace on a test server using 

cimmof -n root/testNamespace CIM_SCHEMA.mof 

which displayed a duplicate class warning (which I expected). I then 
added R/W permissions to the new namespace using 

cimauth -a -u testUser -n root/testNamespace -R -W

and checked if the classes were available using 

cimcli gc -n root/testNamespace CIM_OperatingSystem

However trying to get an instance of a class with

cimcli gi -n root/testNamespace CIM_OperatingSystem 

gives a CIM_ERR_NOT_SUPPORTED error. Upon further investigation I 
realized that no instances of any classes were created when the MOF was 
compiled, so I tried using

cimcli ci -n root/testNamespace CIM_OperatingSystem

but this also gave a CIM_ERR_NOT_SUPPORTED. I feel that I missed a step 
somewhere, or that there is some other recommended way to do this. Can 
anyone provide assistance?

Andreas Maier | 11 Sep 14:08 2014
Picon

Cannot join OP call today


Karl,
I discovered I have a conflict. Sorry for the late notice.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera <at> de.ibm.com, +49-7031-16-3654
________________________________________________________________________
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Ernesto Puig Rodriguez | 27 Aug 10:12 2014
Picon

Re: CIM Client 2.13.0 crashes on Solaris


Hi,

After further tracing I found the place in the code causing the crash. It
is the static definition of IDFactory in the MessageQueue.cpp. More exactly
it is the Array object of the class Stack which seems not to be allocated
correctly. Below a list of tracing:

Entering CIMClient()
Entering MessageQueue::getNextQueueId()
Entering IDFactory::getID()
In IDFactory::getID() after asserting _magic
In IDFactory::getID() 1
In IDFactory::getID() 2
Entering Stack::isEmpty
Entering Array::size()

Moving the definition of IDFactory into the class MessageQueue also did not
help.

Unfortunately I do not see that behaviour when I run the test using the
OpenPegasus program TestClient. This provides the suspicion that the merge
of the standard libraries of Solaris with OpenPegasus may be causing the
problem.

I appreciate any hints or comments on that. Thanks.

Mit freundlichen Gruessen/Kind regards/Atentamen
te

Ernesto Puig Rodriguez

Software Engineer: Tivoli Stor
age FlashCopy Manager
IBM Software Group, Cloud & Smarter Infrastructure

IBM Deutschland Research & Development GmbH
Vorsitze
nde des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehr
ung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Reg
istergericht: Amtsgericht Stuttgart, HRB 243294

Header

 Date:       Thu, 7 Aug 2014 22:43:27 +0200         

 Subject:    CIMClient of version 2.13.0 crashes on 
             Solaris                                

 To:         pegasus-l <at> opengroup.org                

 Sequence:   10194                                  

 From:       Ernesto Puig Rodriguez                 
             <erodrig <at> de.ibm.com>                   

Body: TEXT

Hi All,

I am not able to get running the CIM Client of the rele
ase 2.13.0 for
Solaris. In contrast AIX, Linux an
d HP-UX are working fine.

I am having a core dump creatin
g the object of the CIMClient Pegasus class.
It does n
ot  matter whether it is 32 or 64 bit. The Solaris version I am
using is
the following:
     Oracle Solaris 10 9/10 s10s_u
9wos_14a SPARC  Assembled 11 August 2010

The compiler is
the CC of the sun studio 12.1.

In the past using OpenPegasus 2.9.1, it was working fine.

Is there some experiences
of facing similar issue with OpenPegasus 2.13.0?.

Some mo
re details:
OpenSSL is version 1.0.1h, ICU 4.4.1
Below are
 the last calls in the stack:

$mdb program core
Loading m
odules: [ libc.so.1 ld.so.1 ]
&gt; ::stack
__1cHPegasusFAr
ray4CI_Esize6kM_I_+8(10267e6f8, 10142b050, 10267e700,
1027
3f6c0, 1025b0a98, 4c00)
__1cHPegasusMMessageQdDueueOgetNex
tQdDueueId6F_I_+0x28(10273f590, 4e20,
1025b0a98, cdc60, 18
3ff9c, cdc00)
__1cHPegasusMMessageQdDueue2t5B6Mpkc_v_+0x34
(10273f6a8, 10142b050, cdc00,
10273f6c0, 1025b0a98, 4c00)

__1cHPegasusMCIMClientRep2t6MI_v_+0x58(10273f590, 4e20, 1,
 10273f6a8,
1025b0a98, 10273f5d0)
__1cHPegasusJCIMClient2t
5B6M_v_+0x14(1027058c0, 100340c90, 1, 10273f590,
1027058b0
, 4c00)
....

I would appreciate any help or also a statem
ent of the status of this code
version for the Solaris sup
port.
Thanks.

Andreas Maier | 25 Aug 15:13 2014
Picon

Avoiding PAM checks Bug 9892


Kirk,
On your statement:
> If you use a cookie, then the server will have to request it each time
and cause excess wasted traffic.
I was not aware that in order to use cookies, the server has to turn around
and ask the client. The proposed approach would cause the server to include
the cookie in the response header of the response it sends anyway, and the
client would include the so received cookie in the request header of any
subsequent requests it sends anyway. That would not incur any additional
traffic.
Are you saying that the proposed approach cannot work that way?

On DMTF involvement:
DMTF would be involved to document the concept as an optional feature in
DSP0200, as it does already with a number of other HTTP headers (both
standard and extension). Reason being that DMTF wants to foster
interoperability across *multiple* implementations, instead of just
allowing a particular implementation between its client and server to do
something that is allowed as per the HTTP standard, but otherwise not known
outside of that particular implementation. Now that is Andy's view on how
DMTF operates, but it is with my DMTF hat (particularly the CIM-XML hat)
on.... Plus, IBM uses CIM clients and servers form multiple
implementations, so we have also a company interest for interoperability.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera <at> de.ibm.com, +49-7031-16-3654
________________________________________________________________________
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

----- Forwarded by Andreas Maier/Germany/IBM on 25.08.2014 14:19 -----

From:	Kirk Augustin <kirk_augustin <at> yahoo.com>
To:	Karl Schopmeyer <k.schopmeyer <at> swbell.net>, Jan Safranek
            <jsafrane <at> redhat.com>, Andreas Maier/Germany/IBM <at> IBMDE,
            OpenPegasus Developer mailing list <pegasus-l <at> openpegasus.org>
Date:	31.07.2014 20:50
Subject:	Avoiding PAM checks Bug 9892

Seems overly complicated to me.
The sessionID should be sent by the client with every single packet
transmitted.
If you use a cookie, then the server will have to request it each time and
cause excess wasted traffic.
It does not matter what is in the sessionID, because the point is only for
the server to get back what it expects, regardless of what that is, so I
don't see how the DMTF is involved?
Cookies can return whatever you put into them, but is not really intended
for session integrity, but maintain continuity between sessions.
A lot of client systems do not allow cookies because they take up space and
are server intrusion on the client.
Sure cookies are small, but attacks planting billions of cookies have been
known to happen, once any cookies are allowed.

Kirk  Augustin
11821 NW McNamee Rd
Portland, OR 97231

HM: 503-289-4356

From: Karl Schopmeyer <k.schopmeyer <at> swbell.net>
To: Jan Safranek <jsafrane <at> redhat.com>; Andreas Maier <MAIERA <at> de.ibm.com>;
OpenPegasus Developer mailing list <pegasus-l <at> openpegasus.org>
Sent: Thursday, July 31, 2014 10:47 AM
Subject: Re: Avoiding PAM checks Bug 9892

My real concern was that the design depended on the cookie header which
without some extension to the DMTF protocol specs meant that OpenPegasus
had a "non-compliant" extension as part of its protocol for at least
cim/xml
and that should be considered for the other protocols also (wsman,
etc.). It is
HTTP compliant but not the DMTF specifications.

Given that Andy has agreed that we could propose some part of this to
the DMTF cim/xml
team as a proposed extension, and Jan's responses below which really
represent
a fairly simple solution that only passes the temporary ID back to the
client
in the cookie header (everything else is stored in the server including the
timeout information) which the client must return to ask the server to
bypass
PAM I think we are down to a couple of issues:

1. Exactly what should be in the sessionID.
2. Use of the cookie headers to pass this authentication state
information (sessionID) versus other
    means to pass the information.

SessionID

1. Andy notes that the the exact form of the SessionID is up for
discussion but that
was based on the SessionID carrying real information whereas Jan defined
it as
just a random number ID (all real information is only in the server).
It would
appear that the simple ID proposed is really adequate and that the
server may elect to
test other information received in WBEM requests containing a cookie (IP
address, etc.)
to what level of security it desires.

2.

Protocol Basis for passing session information between server and client

It is clear from the documentation that while there are many recognized
deficiencies throughout
the life of the cookie, it is the dominate mechanism for passing any
type of state information.

My only concern was that we do not want anything that cannot be met by a
conformant WBEM
client (i.e. Open Pegasus secret sauce).  Thus, if we accept that the
concept of the cookie is
the logical way to pass state information like this, then the
significant additional requirement on
the DMTF specifications is that a WBEM client may return a cookie if it
receives a Set-Cookie:
response from the WBEM server and that a WBEM server may include a
Set-Cookie header in
a WBEM response.

This is a specialized and specific use of the cookie header concept. As
such it would appear:

1. The cookie in the WBEM client has a life of a session where the
session is defined by the server and
    possibly limited by the WBEM client.
    If a Set-Cookie: header is received by the client it sends the
cookie back to that server with the subsequent
    operations for the same session and can then discard the cookie.
This is more specific than
    the general use of cookies in a browser/web server environment.
    As such, there is no need for the expiration date option (Expires=)
or the other optional components that
    are defined in RFC 6265 at least for the patches proposed as the
Pegasus implementation.

2. The concept of session is completely by the server. It creates a
session once it
    has validated the request, creates the sessionID, times out the
session, and has a way
    to tell the client when the session has timed out ( error 401,
Unauthorized)

If defined in an extension to the cim/xml specification, the requirement
would simply be that:

    a. The WBEM Server and WBEM client may use the HTTP cookie header
fields as defined in HTTP
        specifications. Note that the original specification was RFC
2109 which was superceeded by
        2965, which was, in turn, superceeded by 6265 so we should be
referenceing 6265 I think.
        This defines the Cookie: and Set-Cookie: header fields

b. A WBEM server may receive a WBEM request message that includes a
cookie header field
        as defined in the HTTP specifications that includes cookies
defined in a previous WBEM
        response message

    c. A Client that receives a WBEM response containing a set-cookie
header should
        return that cookie in the subsequent requests for the same session.

    d. A Server may include a cookie header in a cim/xml response
containing one or
        more cookies based on the HTTP specification.

In fact the only real changes to the DMTF specification are probably
that a WBEM server response
may include a cookie header (set_cookie:) and if it does, the WBEM
client may include that cookie
in subsequent requests.

Note that the current patch defines the cookie name as "PEGASUS_SID"
which is an OpenPegasus
defined name and pretty much ties this particular cookieto OpenPegasus.
Since the cookie name is
server generated and is only to be used to send the cookie back to the
server with the next request
for the same session, the actual name is effectively meaningless.

On 07/31/2014 02:40 AM, Jan Safranek wrote:
> On 07/30/2014 04:34 PM, Andreas Maier wrote:
>> Karl, Jan, I have discussed the issue with a number of folks, and
>> that helped me to better understand how Jan's proposal works.
>>
>> I'd like to make the following comments, before I leave for vacation
>> (back at home from 8/16 on, back in the office from 8/25 on):
>>
>> Just to recap the overall approach: Upon successful authentication of
>> a CIM request, if the server supports the new feature, it invents a
>> session ID and sends that back with the CIM response. If the client
>> supports the new feature, it uses that session ID on subsequent CIM
>> requests. Upon receipt of a CIM request with such a session ID, the
>> server can decide whether it trusts the session ID sufficiently at
>> that moment to bypass the authentication check.
>>
>> I'm fine with that overall approach, but I kept the description
>> deliberately high level, because there are some considerations and
>> requirements:
>>
>> - It depends very much on the data that makes up the session ID. A
>> suggestion from one of our security folks was that the session ID be
>> a hash of (userid, timestamp, randon number, underlying SSL session
>> ID). It is definitely a requirement that the session ID cannot be
>> calculated by an intruder. For example, just using timestamp and
>> userid would probably be not sufficient. Keep in mind that the code
>> is open source, so the algorithm how exactly the hash is calculated
>> will be known, and the secret must be in the data, not in the
>> algorithm. Using the underlying SSL session ID for example ensures
>> that the same SSL session is still in place. Maybe that is too much
>> of a requirement, but it is something that needs to be carefully
>> considered.
>>
> Currently, the session ID is just cryptographically strong* random
> number, nothing else. Timestamp, source IP address and client user name
> are stored (and checked) in Pegasus memory, but are *not* transmitted in
> the session id.
>
> *) 15 bytes (120 bits), generated by RAND_bytes() call from
> openssl/rand.h. I've chose 15 as 'long enough' and divisible by 3, so it
> can be base64-encoded without padding. It can be longer, it's just one
> #define.
>
> I think that adding anything else to the session ID won't improve
> security in any way, it will just make it more predictable. We may store
> (and check) something on server, if we want. I would explicitly avoid
> checking SSL session ID, as the client may use different TCP connection
> (and thus SSL session) for subsequent request - that's very common in
> HTTP world, clients (e.g. pywbem) don't use Keep-Alive that much.
>
>> - The server must be able to determine the lifetime of the session
>> ID. The proposed cookie based approach would probably use the cookie
>> lifetime for that, but that could also be done otherwise. Can cookie
>> lifetimes be modified by a client? That would be bad. I would have a
>> better feeling if the lifetime was encoded in the session ID instead
>> of being a separate piece of clear data. Even if the session ID is a
>> hash (which cannot be unpacked), the server could remember (in
>> memory) which session IDs it has handed out at any point in time, and
>> match the session ID with an internal record of it that shows the
>> lifetime.
> The cookie lifetime is stored on server, client cannot influence it in
> any way. As I wrote above, it's not part of session ID, as it would make
> the ID more predictable.
>
>> - The server must be allowed to decide at any point that a normally
>> valid session ID is nevertheless dismissed, and that a new session ID
>> is created. The server can make that determination based upon nearly
>> everything, including suspicuous client behavior with otherwise
>> valid requests. If the server dismisses an incoming session ID, it
>> performs the normal authentication as if no session ID had been
>> provided by the client, and returns a new session ID.
> Well, there is no code for that, but if someone implements such
> detection logic, it's just one HashTable.remove() call to forget a
> session. which implies that the next request will go through proper
> authentication.
>
>> - As a result, the client must always use the session ID returned by
>> the last response, because the server could have recalculated it.
> Sure, that's how HTTP and my client patches work.
>
>> - how the session ID is transported between client and server, has a
>> number of options. It would certainly be some HTTP header. I have
>> seen extension headers used for that purpose, it does not necessarily
>> have to be a cookie. I find cookies generally suspicious, and don't
>> fully understand to what extent HTTP infrastructure (e.g. proxies)
>> can have a policy to not allow them, in which case a cookie based
>> approach would be limiting in such environments.
> Cookie is described as HTTP 1.0 extension in RFC 2109: HTTP State
> Management Mechanism, released in 1997. It has been revised several
> times and it is part of any decent HTTP implementation for ages. To be
> honest, I haven't looked for any other RFC for session management over
> HTTP, the cookie is really used everywhere.
>
> RFC 2616 (HTTP 1.1) says: Unrecognized header fields SHOULD be ignored
> by the recipient and MUST be forwarded by transparent proxies.
>
> So, client who do not support cookies SHOULD survive just with Basic
> authentication in every request, just like now. And proxies MUST forward
> the cookie.
>
>> - Obviously, it must be optional to support for both client and
>> server. Just to have it mentioned.
> The server is configurable.
>
> What benefit it has to turn it off on _client_ side? If a client
> receives a cookie, it indicates that the server supports it. The client
> just sends it back in subsequent requests. If the server decides that
> the cookie is not enough, the client processed 401 Unauthorized response
> as usual.
>
>> - One important consideration is whether we want it to work with both
>> HTTP and HTTPS, and with all HTTP authentication mechanisms. Someone
>> needs to draw the matrix of HTTP/HTTPS with supported authentication
>> mechanisms, and state for which ones the session ID approach would be
>> supported. That may shape the design significantly. For example, if
>> we supported it only for HTTPS, the session ID would not need to be
>> encrypted. If we also wanted to support it for HTTP, we maybe want to
>> see it encrypted.
> As the session ID is just a random number, encrypting it on HTTP won't
> help much, especially without proper handshake protocol to exchange
> keys, which you don't have on HTTP.
>
> In addition, it looks quite funny that cookie should be encrypted, while
> Basic authentication (the only one that Pegasus supports now) sends user
> password unencrypted in a HTTP header.
>
>
>> - There are sufficient screws and decisions in that whole approach,
>> so that we cannot assume this is just an OpenPegasus addition.
>> DSP0200 documents all standard HTTP headers that play a role in
>> CIM-XML, and it would need to describe this new ability as well. Karl
>> and I are in the CIM-XML WG, and it should not take very long, once
>> we have agreed upon the details on how to do it.
>>
>> To me, the open points are: - how to calculate the session ID. This
>> could be a recommendation for servers to keep them secure, because it
>> is opaque for clients. - which mechanism to use to transport the
>> session ID between client and server.
> I hope I explained my design and implementation above, feel free to ask
> anything.
>
> Jan
>

Ernesto Puig Rodriguez | 7 Aug 22:43 2014
Picon

CIMClient of version 2.13.0 crashes on Solaris


Hi All,

I am not able to get the CIM Client of the release 2.13.0 running for
Solaris.  In contrast AIX, Linux and HP-UX are working fine.

I am having a core dump creating the object of the CIMClient Pegasus class.
It doesn't  matter whether 32 or 64 bit. The Solaris version I am using is
the following:
     Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC  Assembled 11 August 2010

The compiler is the CC of the sun studio 12.1.

In the past it was working fine using OpenPegasus 2.9.1.

Is there some experiences of facing similar issue with OpenPegasus 2.13.0?.

Some more details:
OpenSSL is version 1.0.1h, ICU 4.4.1
Below are the last calls in the stack:

$mdb program core
Loading modules: [ libc.so.1 ld.so.1 ]
> ::stack
__1cHPegasusFArray4CI_Esize6kM_I_+8(10267e6f8, 10142b050, 10267e700,
10273f6c0, 1025b0a98, 4c00)
__1cHPegasusMMessageQdDueueOgetNextQdDueueId6F_I_+0x28(10273f590, 4e20,
1025b0a98, cdc60, 183ff9c, cdc00)
__1cHPegasusMMessageQdDueue2t5B6Mpkc_v_+0x34(10273f6a8, 10142b050, cdc00,
10273f6c0, 1025b0a98, 4c00)
__1cHPegasusMCIMClientRep2t6MI_v_+0x58(10273f590, 4e20, 1, 10273f6a8,
1025b0a98, 10273f5d0)
__1cHPegasusJCIMClient2t5B6M_v_+0x14(1027058c0, 100340c90, 1, 10273f590,
1027058b0, 4c00)
....

I would appreciate any help or also a statement of the status of this code
version for the Solaris support.
Thanks.

Mit freundlichen Grüßen/Kind regards/Atentamente

Ernesto Puig Rodriguez

Software Engineer: Tivoli Storage FlashCopy Manager
IBM Software Group, Tivoli
3848

                                                                                                       

                                                                                                       

 Phone:            +49-7031-16-4965               IBM Deutschland                                      

 E-Mail:           erodrig <at> de.ibm.com             Schoenaicher Str. 220                                

                                                  71032 Boeblingen                                     

                                                  Germany                                              

                                                                                                       

                                                                                                       

 IBM Deutschland                                                                                       
 Research &                                                                                            
 Development                                                                                           
 GmbH /                                                                                                
 Vorsitzende des                                                                                       
 Aufsichtsrats:                                                                                        
 Martina Koederitz                                                                                     
 Geschäftsführung:                                                                                     
 Dirk Wittkopp                                                                                         
 Sitz der                                                                                              
 Gesellschaft:                                                                                         
 Böblingen /                                                                                           
 Registergericht:                                                                                      
 Amtsgericht                                                                                           
 Stuttgart, HRB                                                                                        
 243294                                                                                                

Andreas Maier | 30 Jul 16:34 2014
Picon

Avoiding PAM checks


Karl, Jan,
I have discussed the issue with a number of folks, and that helped me to
better understand how Jan's proposal works.

I'd like to make the following comments, before I leave for vacation (back
at home from 8/16 on, back in the office from 8/25 on):

Just to recap the overall approach: Upon successful authentication of a CIM
request, if the server supports the new feature, it invents a session ID
and sends that back with the CIM response. If the client supports the new
feature, it uses that session ID on subsequent CIM requests. Upon receipt
of a CIM request with such a session ID, the server can decide whether it
trusts the session ID sufficiently at that moment to bypass the
authentication check.

I'm fine with that overall approach, but I kept the description
deliberately high level, because there are some considerations and
requirements:

- It depends very much on the data that makes up the session ID. A
   suggestion from one of our security folks was that the session ID be a
   hash of (userid, timestamp, randon number, underlying SSL session ID).
   It is definitely a requirement that the session ID cannot be calculated
   by an intruder. For example, just using timestamp and userid would
   probably be not sufficient. Keep in mind that the code is open source,
   so the algorithm how exactly the hash is calculated will be known, and
   the secret must be in the data, not in the algorithm. Using the
   underlying SSL session ID for example ensures that the same SSL session
   is still in place. Maybe that is too much of a requirement, but it is
   something that needs to be carefully considered.

- The server must be able to determine the lifetime of the session ID. The
   proposed cookie based approach would probably use the cookie lifetime
   for that, but that could also be done otherwise. Can cookie lifetimes be
   modified by a client? That would be bad. I would have a better feeling
   if the lifetime was encoded in the session ID instead of being a
   separate piece of clear data. Even if the session ID is a hash (which
   cannot be unpacked), the server could remember (in memory) which session
   IDs it has handed out at any point in time, and match the session ID
   with an internal record of it that shows the lifetime.

- The server must be allowed to decide at any point that a normally valid
   session ID is nevertheless dismissed, and that a new session ID is
   created. The server can make that determination based upon nearly
   everything, including suspicuous client behavior with otherwise valid
   requests. If the server dismisses an incoming session ID, it performs
   the normal authentication as if no session ID had been provided by the
   client, and returns a new session ID.

- As a result, the client must always use the session ID returned by the
last response, because the server could have recalculated it.

- how the session ID is transported between client and server, has a number
   of options. It would certainly be some HTTP header. I have seen
   extension headers used for that purpose, it does not necessarily have to
   be a cookie. I find cookies generally suspicious, and don't fully
   understand to what extent HTTP infrastructure (e.g. proxies) can have a
   policy to not allow them, in which case a cookie based approach would be
   limiting in such environments.

- Obviously, it must be optional to support for both client and server.
Just to have it mentioned.

- One important consideration is whether we want it to work with both HTTP
   and HTTPS, and with all HTTP authentication mechanisms. Someone needs to
   draw the matrix of HTTP/HTTPS with supported authentication mechanisms,
   and state for which ones the session ID approach would be supported.
   That may shape the design significantly. For example, if we supported it
   only for HTTPS, the session ID would not need to be encrypted. If we
   also wanted to support it for HTTP, we maybe want to see it encrypted.

- There are sufficient screws and decisions in that whole approach, so that
   we cannot assume this is just an OpenPegasus addition. DSP0200 documents
   all standard HTTP headers that play a role in CIM-XML, and it would need
   to describe this new ability as well. Karl and I are in the CIM-XML WG,
   and it should not take very long, once we have agreed upon the details
   on how to do it.

To me, the open points are:
- how to calculate the session ID. This could be a recommendation for
servers to keep them secure, because it is opaque for clients.
- which mechanism to use to transport the session ID between client and
server.

Andy

Andreas Maier
IBM Senior Technical Staff Member, Systems Management Architecture & Design
IBM Research & Development Laboratory Boeblingen, Germany
maiera <at> de.ibm.com, +49-7031-16-3654
________________________________________________________________________
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Prakash Narayanaswamy | 15 Jul 03:25 2014

Fwd: On PG_ProviderProfileCapabilities

Hello,

To gain understanding of the modelling required to support SNIA's Array profile, I'm wondering if it's possible to model all the classes, instances and the associations statically in a mof and load it into OpenPegasus.

If this is possible, how can I register support for Array profile in OpenPegasus without writing a PG_ProviderModule and the associated PG_ProviderProfileCapabilities.

​Prakash 


Cheng Yong CY Zhao | 12 May 04:36 2014
Picon

A question about PEGASUS_INTEROP_NAMESPACE

Hello,

I set PEGASUS_INTEROP_NAMESPACE=interop PEGASUS_ENABLE_DMTF_INDICATION_PROFILE_SUPPORT=true and PEGASUS_ENABLE_INTEROP_PROVIDER=true to enable indications support. I got following errors when trying to ei PG_ComputerSystem, CIM_ComputerSystem:

CLI CIMException:  Cmd= ei Object= PG_ComputerSystem
CIM_ERR_INVALID_NAMESPACE: root/cimv2

CLI CIMException:  Cmd= ei Object= CIM_ComputerSystem
root/cimv2

do I set wrong build options? Thank you.

Regards,
Cheney
Sheng SH Liu | 9 May 08:46 2014
Picon

A question about comprovagt accessing storage nodes

Hi all:
we are using cimprovagt and get some error.
we check the log and see following:

type=AVC msg=audit(1394502919.480:2066713): avc:  denied  { getattr } for  pid=32761 comm="cimprovagt" path="/dev/dm-7" dev=devtmpfs ino=31093 scontext=system_u:system_r:pegasus_t:s0 tcontext=system_u:object_r:svirt_image_t:s0:c43,c115 tclass=blk_file
type=SYSCALL msg=audit(1394502919.480:2066713): arch=c000003e syscall=4 success=no exit=-13 a0=7f72b80186f0 a1=7f72f9a17040 a2=7f72f9a17040 a3=0 items=0 ppid=19642 pid=32761 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cimprovagt" exe="/usr/sbin/cimprovagt" subj=system_u:system_r:pegasus_t:s0 key=(null)

here /dev/dm-7 is a guest storage nodes.
Should comprovagt legitimitely be accessing guest storage nodes?

Thanks!
Best Regards!


Gmane