[389-devel] plugin problem using slapi_entry_attr_find

Nathan Kinder nkinder at redhat.com
Thu Jan 16 23:35:14 UTC 2014


On 01/16/2014 03:14 PM, Deas, Jim wrote:
> Rich,
> 
> Thanks. I actually did have the address of operator on the code. Both
> the init and config are defining only a couple of specific functions
> (start_fn, pre_results_fn,pre_abandon_fn) one function defined for each.
> 
> The one I am testing is  preop_results() which does trigger, works as
> you suggested below, but crashes when adding a call to
> slapi_entry_attr_find() for many but not all remote inquiries.

In the code you shared, you are setting "e" with this call:

  slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &e)

The issue here is that "e" is a Slapi_Entry, but SLAPI_SEARCH_ATTRS
doesn't retreive a Slapi_Entry from the pblock.  This means "e" is
incorrect at this point (it will likely have bad pointer values if you
look into it in gdb).

When you call slapi_entry_attr_find(), it is likely trying to
dereference some of these bad pointer values, which leads to the crash.
 You need to pass a valid Slapi_Entry to this function (if you even need
this function).

What exactly are you trying to have your plug-in do?

Thanks,
-NGK
> 
> Perhaps I am going at this all wrong. What sequence should I call to get
> a multivariable attribute? In this case a list of attribute ‘memberUid’
> while rejecting preop_results not directed at returning Group information?
> 
>  
> 
> JD
> 
>  
> 
> *From:*389-devel-bounces at lists.fedoraproject.org
> [mailto:389-devel-bounces at lists.fedoraproject.org] *On Behalf Of *Rich
> Megginson
> *Sent:* Thursday, January 16, 2014 2:25 PM
> *To:* 389 Directory server developer discussion.
> *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find
> 
>  
> 
> Another bug in your code.  The argument for SLAPI_SEARCH_ATTRS should be
> the address of a char **.e.g.
> 
> {
>     char **attrs;
>     int ii = 0;
>     ...
>     if (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &attrs) !=0 )return (-1);
>     for (ii = 0; attrs && attrs[ii]; ++ii) {
>         slapi_log_error(SLAPI_LOG_PLUGIN, "my plugin",
>                                  "search attr %d is %s\n", ii, attrs[ii]);
>     }
>     ...
> 
> In your plugin entry and in your plugin config you specify which types
> of operations (bind, search, add, etc.) your plugin will handle.
> E.g. a SLAPI_PLUGIN_PRE_BIND_FN will be called at the pre-operation
> stage of a BIND operation.
> 
> Each type of plugin will have possibly different pblock parameters
> available.  So, for example, if you use the same function as both a bind
> preop and a search preop - when called as a bind preop, the
> SLAPI_SEARCH_ATTRS will not be available.
> 
> If you want to use the same function for different op types, declare
> different functions for each op type, then call your common function
> with the op type, like this:
> 
> int
> bind_preop(Slapi_PBlock *pb) {
>     return common_function(SLAPI_PLUGIN_PRE_BIND_FN, pb);
> }
> 
> int
> search_preop(Slapi_PBlock *pb) {
>     return common_function(SLAPI_PLUGIN_PRE_SEARCH_FN, pb);
> }
> ...
> 
> int
> common_function(int type, Slapi_PBlock *pb) {
>     ...
>     if (type == SLAPI_PLUGIN_PRE_BIND_FN) {
>        do some bind specific action
>     } else if (type == SLAPI_PLUGIN_PRE_SEARCH_FN) {
>        do some search specific action
>     }
>     ...
> 
> On 01/16/2014 03:02 PM, Deas, Jim wrote:
> 
>     On further review it appears that the line in question will crash
>     Dirsrv on some request from PAM or even 389-Console but not when
>     searching groups via ldapsearch
> 
>     Should there be a statement that determines what type of query
>     triggered the preop_result so I know if it’s proper  to look for
>     attributes?
> 
>      
> 
>      
> 
>     *From:*389-devel-bounces at lists.fedoraproject.org
>     <mailto:389-devel-bounces at lists.fedoraproject.org>
>     [mailto:389-devel-bounces at lists.fedoraproject.org] *On Behalf Of
>     *Rich Megginson
>     *Sent:* Thursday, January 16, 2014 11:29 AM
>     *To:* 389 Directory server developer discussion.
>     *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find
> 
>      
> 
>     On 01/16/2014 11:39 AM, Deas, Jim wrote:
> 
>         My bet, a rookie mistake. Am I forgetting to init a pointer etc???
> 
>         Adding  the line surrounded by ******  in this routine makes
>         dirsrv unstable and crashes it after a few queries.
> 
>          
> 
>          
> 
>          
> 
>          
> 
>         /* Registered preop_result routine */
> 
>         int gnest_preop_results( Slapi_PBlock *pb){
> 
>                         Slapi_Entry *e;
> 
>                         Slapi_Attr  **a;
> 
>     This should be Slapi_Attr *a;
> 
> 
>      
> 
>     If (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &e) !=0 )return (-1);
> 
>      
> 
>     /*****************This line makes the server unstable and crashes it
>     after one or two queries ********************/
> 
>     If(slapi_entry_attr_find(e, “memberUid”,&a) == 0)
>     slapi_log_error(SLAPI_LOG_PLUGIN, “gnest preop”,”memberUid  found in
>     record);
> 
>     /******************************************************************************************************/
> 
>      
> 
>      
> 
>     Return (0);
> 
>     }
> 
>      
> 
>     *JD*
> 
>      
> 
> 
> 
> 
> 
>     --
> 
>     389-devel mailing list
> 
>     389-devel at lists.fedoraproject.org <mailto:389-devel at lists.fedoraproject.org>
> 
>     https://admin.fedoraproject.org/mailman/listinfo/389-devel
> 
>      
> 
> 
> 
> 
>     --
> 
>     389-devel mailing list
> 
>     389-devel at lists.fedoraproject.org <mailto:389-devel at lists.fedoraproject.org>
> 
>     https://admin.fedoraproject.org/mailman/listinfo/389-devel
> 
>  
> 
> 
> 
> --
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
> 



More information about the 389-devel mailing list