[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