[389-devel] plugin problem using slapi_entry_attr_find
Deas, Jim
James.Deas at warnerbros.com
Thu Jan 16 23:49:47 UTC 2014
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
-----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
More information about the 389-devel
mailing list