<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Praveen,<br>
<br>
This case mostly happens in the longDn upgraded system, but
there're still some NTF producers/consumers have not yet supported
longDn.<br>
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.<br>
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.<br>
<br>
Hi AndersBj,<br>
<br>
Please see my comment in line<br>
<br>
Thanks,<br>
Minh<br>
On 9/24/2014 8:05 PM, Anders Bjornerstedt wrote:<br>
</div>
<blockquote
cite="mid:%2fp%2fopensaf%2ftickets%2f1114%2f77c0e65300d7e941b20ef4c9b5a47e101ce78...@esessmb209.ericsson.se"
type="cite">
<div class="markdown_content">
<p>If this is a case of an NTF callback being invoked towards an
NTF client that does not support longDNs,<br>
yet a long DN pops up from the server, then that should be
detected in the NTF client library and the callback<br>
should not be generated towards the client. If the callback
has a return code (towards the server) then<br>
the library could set it to ERR_NAME_TOO_LONG, or to some
other error, or even OK, depending on the<br>
semantics of the callback.</p>
</div>
</blockquote>
[Minh]: I agree that library returns ERR_NAME_TOO_LONG in
notificationCallback<br>
<blockquote
cite="mid:%2fp%2fopensaf%2ftickets%2f1114%2f77c0e65300d7e941b20ef4c9b5a47e101ce78...@esessmb209.ericsson.se"
type="cite">
<div class="markdown_content">
<p>If it is a case of an NTF downcall from the NTF client (that
does not support long DNs) and the call gets a<br>
reply that fills in an SaNameT value and that value is a long
DN, then the SaNameT should not be set and<br>
an error of SA_AIS_ERR_NAME_TOO_LONG returned to the client.</p>
</div>
</blockquote>
[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.<br>
<blockquote
cite="mid:%2fp%2fopensaf%2ftickets%2f1114%2f77c0e65300d7e941b20ef4c9b5a47e101ce78...@esessmb209.ericsson.se"
type="cite">
<div class="markdown_content">
<p>If the above was not relevant then please ignore.</p>
<p>/AndersBj</p>
<hr>
<p>From: Praveen <span>[<a class="moz-txt-link-freetext"
href="mailto:[email protected]";>mailto:[email protected]</a>]</span><br>
Sent: den 24 september 2014 11:54<br>
To: <a class="moz-txt-link-abbreviated"
href="mailto:[email protected]";>[email protected]</a><br>
Subject: <a moz-do-not-send="true" class="alink"
href="http://sourceforge.net/p/opensaf/tickets/_discuss";>[tickets]</a>
<span>[opensaf:tickets]</span> Re: #1114 NTF: Unadapted
LongDns consumer crashes due to read/subsribe long dn
notification</p>
<p>Hi Minh,<br>
Please see comments inline with <span>[Praveen]</span>.</p>
<p>Thanks,<br>
Praveen</p>
<p>On 24-Sep-14 9:24 AM, Minh Hon Chau wrote:</p>
<p>The following NTF APIs need to add the protection for
unadapted<br>
producer/consumer against the notification containing any
extended<br>
SaNameT, which hereby is known as long DN notification:<br>
1 - saNtfNotificationSend returns SA_AIS_ERR_INVALID_PARAM if
one of the<br>
following statements is true:<br>
. Notification header contains notificationObject or
notifyingObject as<br>
long DN, or any extended SaNameT exists in additionalInfo<br>
. As alarm notification, any field of<br>
specificProblems/thresholdInformation/proposedRepairActions/monitoredAttributes<br>
contains extended SaNameT<br>
. As security alarm notification, any field of<br>
serviceUser/serviceProvider contains extended SaNameT<br>
Execeptionally, the changedAttributes of AttributeChange
notification<br>
and the objectAttributes of ObjectCreateDelete notification,
have<br>
currently treated the value type SA_NTF_VALUE_LDAP_NAME as<br>
SA_NTF_VALUE_STRING, so that there's no need to add the
protection for<br>
unadapted producer against changeAttributes and
objectAttributes.</p>
<p><span>[Praveen]</span>For using long Dns in the notification,
a notification producer<br>
(sender) will either set "SA_ENABLE_EXTENDED_NAMES" for using
long Dns<br>
or compile application with "-DSA_EXTENDED_NAME_SOURCE".</p>
<p>If an application is unadapted to long Dns it means it is
neither<br>
compiled with the flag not it setting the
"SA_ENABLE_EXTENDED_NAMES" and<br>
hence it is sending the shot Dn only.<br>
The how such an application can fill long DN as it cannot use
Lend() and<br>
Borrow() APIs.</p>
<p>2 - saNtfNotificationReadInitialize returns
SA_AIS_ERR_INVALID_PARAM if<br>
the reader specifies the filter header containing any long DN
object in<br>
notificationObjects or notifyingObjects.</p>
<p><span>[Praveen]</span> same as above.</p>
<p>3 - saNtfNotificationReadNext skips any notification
containing<br>
notificationObject/notifyingObject as long DN, and continue
reading next<br>
until finding the notification without long DN<br>
notificationObject/notifyingObject then returns SA_AIS_OK, or
no more<br>
notification satisfying the criteria then returns
SA_AIS_ERR_NOT_EXIST.</p>
<p>4 - saNtfNotificationSubscribe returns
SA_AIS_ERR_INVALID_PARAM if the<br>
subscriber specifies the filter header containing any long DN
object in<br>
notificationObjects or notifyingObjects.</p>
<p><span>[Praveen]</span> same as above.</p>
<p>5 - Any Notification callback containing<br>
notificationObject/notifyingObject as long DN is dropped at
Agent and<br>
SA_AIS_NAME_TOO_LONG error code is returned to subscriber.</p>
<p>6 - saNtfPtrValGet returns SA_AIS_ERR_NAME_TOO_LONG if any
extended<br>
SaNameT presents in additionalInfo, specificProblems,<br>
thresholdInformation, proposedRepairActions,
monitoredAttributes,<br>
serviceUser and serviceProvider.</p>
<hr>
<p><a moz-do-not-send="true" class="alink"
href="http://sourceforge.net/p/opensaf/tickets/1114";>[tickets:#1114]</a><a
moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/tickets/1114";>http://sourceforge.net/p/opensaf/tickets/1114</a>
<a moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/tickets/1114";>http://sourceforge.net/p/opensaf/tickets/1114</a>
NTF:<br>
Unadapted LongDns consumer crashes due to read/subsribe long
dn<br>
notification</p>
<p>Status: accepted<br>
Milestone: 4.5.0<br>
Created: Fri Sep 19, 2014 05:15 AM UTC by Minh Hon Chau<br>
Last Updated: Tue Sep 23, 2014 11:18 AM UTC<br>
Owner: Minh Hon Chau</p>
<p>In a long dn upgraded system, currently if an unadapted
producer by<br>
somehow receives the long dn objects then sends out within a<br>
notification, the producer is not able to send this
notification and<br>
receives the IN_VALID_PARAM return code.</p>
<p>Similarly, the unadapted consumer should fail to
read/subscribe for a<br>
long dn notification, rather than crash</p>
<hr>
<p>Sent from sourceforge.net because
<a class="moz-txt-link-abbreviated"
href="mailto:[email protected]";>[email protected]</a><br>
is subscribed to <a moz-do-not-send="true"
href="https://sourceforge.net/p/opensaf/tickets";>https://sourceforge.net/p/opensaf/tickets/</a><a
moz-do-not-send="true"
href="https://sourceforge.net/p/opensaf/tickets";>https://sourceforge.net/p/opensaf/tickets</a><br>
<a moz-do-not-send="true"
href="https://sourceforge.net/p/opensaf/tickets";>https://sourceforge.net/p/opensaf/tickets</a></p>
<p>To unsubscribe from further messages, a project admin can
change<br>
settings at <a moz-do-not-send="true"
href="https://sourceforge.net/p/opensaf/admin/tickets/options.";>https://sourceforge.net/p/opensaf/admin/tickets/options.</a>
Or,<br>
if this is a mailing list, you can unsubscribe from the
mailing list.</p>
<hr>
<p>Meet PCI DSS 3.0 Compliance Requirements with EventLog
Analyzer<br>
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
DSS Reports<br>
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White
paper<br>
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog
Analyzer<br>
<a moz-do-not-send="true"
href="http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk";
rel="nofollow">http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk</a></p>
<hr>
<p>Opensaf-tickets mailing list<br>
<a class="moz-txt-link-abbreviated"
href="mailto:[email protected]";>[email protected]</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/opensaf-tickets";>https://lists.sourceforge.net/lists/listinfo/opensaf-tickets</a></p>
<hr>
<p><a moz-do-not-send="true" class="alink"
href="http://sourceforge.net/p/opensaf/tickets/1114";>[tickets:#1114]</a><a
moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/tickets/1114";>http://sourceforge.net/p/opensaf/tickets/1114</a>
NTF: Unadapted LongDns consumer crashes due to read/subsribe
long dn notification</p>
<p>Status: accepted<br>
Milestone: 4.5.0<br>
Created: Fri Sep 19, 2014 05:15 AM UTC by Minh Hon Chau<br>
Last Updated: Wed Sep 24, 2014 05:06 AM UTC<br>
Owner: Minh Hon Chau</p>
<p>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.</p>
<p>Similarly, the unadapted consumer should fail to
read/subscribe for a long dn notification, rather than crash</p>
<hr>
<p>Sent from sourceforge.net because
<a class="moz-txt-link-abbreviated"
href="mailto:[email protected]";>[email protected]</a>
is subscribed to <a
moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/tickets";>http://sourceforge.net/p/opensaf/tickets/</a><a
moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/tickets";>http://sourceforge.net/p/opensaf/tickets</a></p>
<p>To unsubscribe from further messages, a project admin can
change settings at <a moz-do-not-send="true"
href="http://sourceforge.net/p/opensaf/admin/tickets/options.";>http://sourceforge.net/p/opensaf/admin/tickets/options.</a>
Or, if this is a mailing list, you can unsubscribe from the
mailing list.</p>
<hr>
<p><strong> <a moz-do-not-send="true" class="alink"
href="http://sourceforge.net/p/opensaf/tickets/1114";>[tickets:#1114]</a>
NTF: Unadapted LongDns consumer crashes due to read/subsribe
long dn notification</strong></p>
<p><strong>Status:</strong> accepted<br>
<strong>Milestone:</strong> 4.5.0<br>
<strong>Created:</strong> Fri Sep 19, 2014 05:15 AM UTC by
Minh Hon Chau<br>
<strong>Last Updated:</strong> Wed Sep 24, 2014 05:06 AM UTC<br>
<strong>Owner:</strong> Minh Hon Chau</p>
<p>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.</p>
<p>Similarly, the unadapted consumer should fail to
read/subscribe for a long dn notification, rather than crash</p>
<hr>
<p>Sent from sourceforge.net because you indicated interest in <a
moz-do-not-send="true"
href="https://sourceforge.net/p/opensaf/tickets/1114";>https://sourceforge.net/p/opensaf/tickets/1114/</a></p>
<p>To unsubscribe from further messages, please visit <a
moz-do-not-send="true"
href="https://sourceforge.net/auth/subscriptions";>https://sourceforge.net/auth/subscriptions/</a></p>
</div>
</blockquote>
<br>
</body>
</html>
---
** [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 [email protected] is
subscribed to 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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
