Forwarding to devel list.
-------- Original Message --------
Subject: Re: Fwd: Re: [opensaf:tickets] Re: #1114 NTF: Unadapted LongDns
consumer crashes due to read/subsribe long dn notification
Date: Thu, 25 Sep 2014 11:34:12 +0530
From: praveen malviya <praveen.malv...@oracle.com>
Organization: Oracle Corporation
To: minhchau <minh.c...@dektech.com.au>
CC: Anders Bjornerstedt <anders.bjornerst...@ericsson.com>
On 24-Sep-14 6:11 PM, minhchau wrote:
> Just re-send to you, since I have not seen the ticket updates my reply
> in sourceforge
>
>
> -------- Original Message --------
> Subject: Re: [opensaf:tickets] Re: #1114 NTF: Unadapted LongDns
> consumer crashes due to read/subsribe long dn notification
> Date: Wed, 24 Sep 2014 22:36:48 +1000
> From: minhchau <minh.c...@dektech.com.au>
> To: [opensaf:tickets] <1...@tickets.opensaf.p.re.sf.net>
>
>
>
> Hi Praveen,
>
> This case mostly happens in the longDn upgraded system, but there're
> still some NTF producers/consumers have not yet supported longDn.
> If you complie the ntfread/ntfsubscribe prior than #873, which have not
> supported longDns. Then if bring these unadapted ntftools running in
> Opensaf 4.5, for instance: ntftest 36 1, these unadapted
> ntfread/ntfsubscribe will be crashed to read/subscribe the notification
> generated by ntftest.
> Similarly, if the unadapted producer receives longDns object from
> adapted longDns application, then sends the notification with this
> longDns object, it should not be able to send.
>
[Praveen] What I meant was that problem is with consumers(reader or
subscriber) and not with sender. But an unadapted application can be
receiver and sender at the same time.
Now why the problem is not with unadapted sender application because
in #873 check is already in place for it. Here is the code snippet in
agent code:
static SaAisErrorT checkHeader(SaNtfNotificationHeaderT *nh)
{
int i =0;
if (!ntfsv_sanamet_is_valid(nh->notificationObject) ||
!ntfsv_sanamet_is_valid(nh->notifyingObject)) {
TRACE_1("SaNameT is invaild");
return SA_AIS_ERR_INVALID_PARAM;
}
So such an unadapted sender is already getting INVALID_PARAM.
Thanks,
Praveen
> Hi AndersBj,
>
> Please see my comment in line
>
> Thanks,
> Minh
> On 9/24/2014 8:05 PM, Anders Bjornerstedt wrote:
>>
>> If this is a case of an NTF callback being invoked towards an NTF
>> client that does not support longDNs,
>> yet a long DN pops up from the server, then that should be detected in
>> the NTF client library and the callback
>> should not be generated towards the client. If the callback has a
>> return code (towards the server) then
>> the library could set it to ERR_NAME_TOO_LONG, or to some other error,
>> or even OK, depending on the
>> semantics of the callback.
>>
> [Minh]: I agree that library returns ERR_NAME_TOO_LONG in
> notificationCallback
[Praveen] I did not get this. Does it mean returning ERR_NAME_TOO_LONG
to server?
>>
>> If it is a case of an NTF downcall from the NTF client (that does not
>> support long DNs) and the call gets a
>> reply that fills in an SaNameT value and that value is a long DN, then
>> the SaNameT should not be set and
>> an error of SA_AIS_ERR_NAME_TOO_LONG returned to the client.
>>
> [Minh]: Prior than #873, if NTF client sends notification having SaNameT
> >=256, ERR_INVALID_PARAM is returned to client. So I think
> ERR_INVALID_PARAM should also be applicable here.
>>
>> If the above was not relevant then please ignore.
>>
>> /AndersBj
>>
>> ------------------------------------------------------------------------
>>
>> From: Praveen [mailto:praveenmalv...@users.sf.net]
>> Sent: den 24 september 2014 11:54
>> To: opensaf-tick...@lists.sourceforge.net
>> Subject: [tickets] <http://sourceforge.net/p/opensaf/tickets/_discuss>
>> [opensaf:tickets] Re: #1114 NTF: Unadapted LongDns consumer crashes
>> due to read/subsribe long dn notification
>>
>> Hi Minh,
>> Please see comments inline with [Praveen].
>>
>> Thanks,
>> Praveen
>>
>> On 24-Sep-14 9:24 AM, Minh Hon Chau wrote:
>>
>> The following NTF APIs need to add the protection for unadapted
>> producer/consumer against the notification containing any extended
>> SaNameT, which hereby is known as long DN notification:
>> 1 - saNtfNotificationSend returns SA_AIS_ERR_INVALID_PARAM if one of the
>> following statements is true:
>> . Notification header contains notificationObject or notifyingObject as
>> long DN, or any extended SaNameT exists in additionalInfo
>> . As alarm notification, any field of
>> specificProblems/thresholdInformation/proposedRepairActions/monitoredAttributes
>> contains extended SaNameT
>> . As security alarm notification, any field of
>> serviceUser/serviceProvider contains extended SaNameT
>> Execeptionally, the changedAttributes of AttributeChange notification
>> and the objectAttributes of ObjectCreateDelete notification, have
>> currently treated the value type SA_NTF_VALUE_LDAP_NAME as
>> SA_NTF_VALUE_STRING, so that there's no need to add the protection for
>> unadapted producer against changeAttributes and objectAttributes.
>>
>> [Praveen]For using long Dns in the notification, a notification producer
>> (sender) will either set "SA_ENABLE_EXTENDED_NAMES" for using long Dns
>> or compile application with "-DSA_EXTENDED_NAME_SOURCE".
>>
>> If an application is unadapted to long Dns it means it is neither
>> compiled with the flag not it setting the "SA_ENABLE_EXTENDED_NAMES" and
>> hence it is sending the shot Dn only.
>> The how such an application can fill long DN as it cannot use Lend() and
>> Borrow() APIs.
>>
>> 2 - saNtfNotificationReadInitialize returns SA_AIS_ERR_INVALID_PARAM if
>> the reader specifies the filter header containing any long DN object in
>> notificationObjects or notifyingObjects.
>>
>> [Praveen] same as above.
>>
>> 3 - saNtfNotificationReadNext skips any notification containing
>> notificationObject/notifyingObject as long DN, and continue reading next
>> until finding the notification without long DN
>> notificationObject/notifyingObject then returns SA_AIS_OK, or no more
>> notification satisfying the criteria then returns SA_AIS_ERR_NOT_EXIST.
>>
>> 4 - saNtfNotificationSubscribe returns SA_AIS_ERR_INVALID_PARAM if the
>> subscriber specifies the filter header containing any long DN object in
>> notificationObjects or notifyingObjects.
>>
>> [Praveen] same as above.
>>
>> 5 - Any Notification callback containing
>> notificationObject/notifyingObject as long DN is dropped at Agent and
>> SA_AIS_NAME_TOO_LONG error code is returned to subscriber.
>>
>> 6 - saNtfPtrValGet returns SA_AIS_ERR_NAME_TOO_LONG if any extended
>> SaNameT presents in additionalInfo, specificProblems,
>> thresholdInformation, proposedRepairActions, monitoredAttributes,
>> serviceUser and serviceProvider.
>>
>> ------------------------------------------------------------------------
>>
>> [tickets:#1114]
>> <http://sourceforge.net/p/opensaf/tickets/1114>http://sourceforge.net/p/opensaf/tickets/1114
>> http://sourceforge.net/p/opensaf/tickets/1114 NTF:
>> Unadapted LongDns consumer crashes due to read/subsribe long dn
>> notification
>>
>> Status: accepted
>> Milestone: 4.5.0
>> Created: Fri Sep 19, 2014 05:15 AM UTC by Minh Hon Chau
>> Last Updated: Tue Sep 23, 2014 11:18 AM UTC
>> Owner: Minh Hon Chau
>>
>> In a long dn upgraded system, currently if an unadapted producer by
>> somehow receives the long dn objects then sends out within a
>> notification, the producer is not able to send this notification and
>> receives the IN_VALID_PARAM return code.
>>
>> Similarly, the unadapted consumer should fail to read/subscribe for a
>> long dn notification, rather than crash
>>
>> ------------------------------------------------------------------------
>>
>> Sent from sourceforge.net because opensaf-tick...@lists.sourceforge.net
>> is subscribed to https://sourceforge.net/p/opensaf/tickets/
>> <https://sourceforge.net/p/opensaf/tickets>https://sourceforge.net/p/opensaf/tickets
>> https://sourceforge.net/p/opensaf/tickets
>>
>> To unsubscribe from further messages, a project admin can change
>> settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or,
>> if this is a mailing list, you can unsubscribe from the mailing list.
>>
>> ------------------------------------------------------------------------
>>
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>
>> ------------------------------------------------------------------------
>>
>> Opensaf-tickets mailing list
>> opensaf-tick...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
>>
>> ------------------------------------------------------------------------
>>
>> [tickets:#1114]
>> <http://sourceforge.net/p/opensaf/tickets/1114>http://sourceforge.net/p/opensaf/tickets/1114
>> NTF: Unadapted LongDns consumer crashes due to read/subsribe long dn
>> notification
>>
>> Status: accepted
>> Milestone: 4.5.0
>> Created: Fri Sep 19, 2014 05:15 AM UTC by Minh Hon Chau
>> Last Updated: Wed Sep 24, 2014 05:06 AM UTC
>> Owner: Minh Hon Chau
>>
>> In a long dn upgraded system, currently if an unadapted producer by
>> somehow receives the long dn objects then sends out within a
>> notification, the producer is not able to send this notification and
>> receives the IN_VALID_PARAM return code.
>>
>> Similarly, the unadapted consumer should fail to read/subscribe for a
>> long dn notification, rather than crash
>>
>> ------------------------------------------------------------------------
>>
>> Sent from sourceforge.net because
>> opensaf-tick...@lists.sourceforge.net is subscribed to
>> http://sourceforge.net/p/opensaf/tickets/
>> <http://sourceforge.net/p/opensaf/tickets>http://sourceforge.net/p/opensaf/tickets
>>
>> To unsubscribe from further messages, a project admin can change
>> settings at http://sourceforge.net/p/opensaf/admin/tickets/options.
>> Or, if this is a mailing list, you can unsubscribe from the mailing list.
>>
>> ------------------------------------------------------------------------
>>
>> *[tickets:#1114] <http://sourceforge.net/p/opensaf/tickets/1114> NTF:
>> Unadapted LongDns consumer crashes due to read/subsribe long dn
>> notification*
>>
>> *Status:* accepted
>> *Milestone:* 4.5.0
>> *Created:* Fri Sep 19, 2014 05:15 AM UTC by Minh Hon Chau
>> *Last Updated:* Wed Sep 24, 2014 05:06 AM UTC
>> *Owner:* Minh Hon Chau
>>
>> In a long dn upgraded system, currently if an unadapted producer by
>> somehow receives the long dn objects then sends out within a
>> notification, the producer is not able to send this notification and
>> receives the IN_VALID_PARAM return code.
>>
>> Similarly, the unadapted consumer should fail to read/subscribe for a
>> long dn notification, rather than crash
>>
>> ------------------------------------------------------------------------
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/opensaf/tickets/1114/
>> <https://sourceforge.net/p/opensaf/tickets/1114>
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/
>> <https://sourceforge.net/auth/subscriptions>
>>
>
>
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
