[389-devel] plugin problem using slapi_entry_attr_find
Rich Megginson
rmeggins at redhat.com
Thu Jan 16 23:55:56 UTC 2014
On 01/16/2014 04:49 PM, Deas, Jim wrote:
> I caught the pointer issue after my last post. I misunderstood the process thinking I have to download a master pblock then use a reference from that for obtaining values.
> I am trying to intercept queries that are returning posix group information and make dynamic changes in the memberUid list returned to the client.
> The purpose is to create a single nested group layer handled on the dirsrv side so existing Linux PAM systems do not need modification to use simple nested groups.
>
> *In the database, I have memeberUid values preceeded by '@' to designate them as group entries instead of people. I.E. memberUid = betty,fred,joan, at accountants for three users and all users part of group accountants.
>
> Process:
> Capture results
> Internal search for any @* as additional groups
> Remove @* and add found subgroups memberUid's to the existing results
Ok. Then you will want to use a SLAPI_PLUGIN_PRE_ENTRY_FN plugin. I
would suggest taking a look at the deref plugin code, which does
something very similar - just before an entry is to be returned, the
deref plugin adds some extra data to the entry to be returned. deref
defines two plugin functions - a SLAPI_PLUGIN_PRE_SEARCH_FN and a
SLAPI_PLUGIN_PRE_ENTRY_FN. It is the latter that does the work of
adding the extra data to the entry to be returned to the user.
>
>
>
>
>
> -----Original Message-----
> From: 389-devel-bounces at lists.fedoraproject.org [mailto:389-devel-bounces at lists.fedoraproject.org] On Behalf Of Nathan Kinder
> Sent: Thursday, January 16, 2014 3:35 PM
> To: 389 Directory server developer discussion.
> Subject: Re: [389-devel] plugin problem using slapi_entry_attr_find
>
> 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
>>
> --
> 389-devel mailing list
> 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