- **status**: unassigned --> accepted
- **assigned_to**: Anders Bjornerstedt
- **Part**: lib --> nd
- **Priority**: major --> critical
- **Comment**:

Changing severity to critical since this defect is a blocker for 
usage of long DNs.



---

** [tickets:#1204] IMM: Short parent DN + RDN can result in long DN in create 
callback**

**Status:** accepted
**Milestone:** 4.5.1
**Created:** Thu Nov 06, 2014 03:15 PM UTC by Anders Bjornerstedt
**Last Updated:** Thu Nov 06, 2014 03:15 PM UTC
**Owner:** Anders Bjornerstedt

One case of protecting OI clients that can not handle long DNs, from getting
callbacks that include or imply long DNs has been forgotten in 4.5.

This is the case of a ccb-create callback where the parent DN is shorter than
256 bytes, but when the RDN attribute is added the resulting new object DN
becomes longer than 256 bytes (including null termination).

Note that the case where the parent DN itself is long and the client is
incapable is handled in the current 4.5 library code for ccbCreate callback.

This is complicated by the fact that the generic client library code does not
know which attribute is the RDN attribute. 

The suggested solution is that the immnd server in the message to the client 
always include a flag indicating if a create callback implies a long DN.

The generic client library code can then just check this flag and compare with
the clients setting for longDN capability or not. If the client is incapable
of handling long DNs, the callback bounces back to the server with error
without involving the application level OI, in the same way as a modify/delete
callback should do if the DN is long and client is incapable.

The object-create-callback in the new SaStringT based API avoids this awkward
special problem with the old create callback. In the new API the create callback
simply contains the DN of the object proposed for creation, symetric with modify
and delete callbacks. This relieves the OI from having to deal with the messy
RDN concept. 



---

Sent from sourceforge.net because [email protected] is 
subscribed to 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.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

Reply via email to