12:39 p.m.
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;
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
1:28 p.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
4:02 p.m.
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(a)lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org<mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
4:24 p.m.
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@lists.fedoraproject.org
[mailto:389-devel-bounces@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(a)lists.fedoraproject.org <mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
5:14 p.m.
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.
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(a)lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org<mailto:389-devel-bounces@lists.fedoraproject.org>
[mailto:389-devel-bounces@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@lists.fedoraproject.org<mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@lists.fedoraproject.org<mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
5:35 p.m.
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@lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org
<mailto:389-devel-bounces@lists.fedoraproject.org>
[mailto:389-devel-bounces@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(a)lists.fedoraproject.org <mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org <mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
5:49 p.m.
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,@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(a)lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org
<mailto:389-devel-bounces@lists.fedoraproject.org>
[mailto:389-devel-bounces@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(a)lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
<mailto:389-devel@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
5:55 p.m.
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,@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(a)lists.fedoraproject.org
[mailto:389-devel-bounces@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@lists.fedoraproject.org
> [mailto:389-devel-bounces@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@lists.fedoraproject.org
> <mailto:389-devel-bounces@lists.fedoraproject.org>
> [mailto:389-devel-bounces@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(a)lists.fedoraproject.org
> <mailto:389-devel@lists.fedoraproject.org>
>
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
>
>
>
>
>
> --
>
> 389-devel mailing list
>
> 389-devel(a)lists.fedoraproject.org
> <mailto:389-devel@lists.fedoraproject.org>
>
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
>
>
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
12:20 p.m.
New subject: plugin PRE_ENTRY_FN scope
Should I be able to use SLAPI_SEARCH_ATTR to view attributes about to be returned to the
client in PRE_ENTRY_FN? Can I start a new search inside PRE_ENTRY_FN to find values needed
to augment the existing attributes being returned?
12:31 p.m.
New subject: plugin PRE_ENTRY_FN scope
On 01/17/2014 11:20 AM, Deas, Jim wrote:
Should I be able to use SLAPI_SEARCH_ATTR to view attributes about to
be returned to the client in PRE_ENTRY_FN?
Yes, looks like it, but you have to be prepared for the case where a
client does not specify a search attribute list - in this case, the
client is asking for all non-operational attributes in the entry.
Can I start a new search inside PRE_ENTRY_FN to find values needed
to augment the existing attributes being returned?
Yes, that should work. However, doing this parsing and internal search
for every single entry returned might be a big performance hit. You
might want to examine the SLAPI_SEARCH_ATTRS and do the internal search
in a SLAPI_PLUGIN_PRE_SEARCH_FN, then store the results in the operation
(in an operation extension), then just use those results in your
PRE_ENTRY_FN. This is what the deref plugin does.
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
1:02 p.m.
New subject: plugin PRE_ENTRY_FN scope
Rich,
Thanks so much!
Are you suggesting I do an internal search in PRE_SARCH_FN then use the return to modify
the original search request to include additional items before allowing the original
client search to begin?
-----Original Message-----
From: 389-devel-bounces(a)lists.fedoraproject.org
[mailto:389-devel-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Friday, January 17, 2014 10:32 AM
To: 389 Directory server developer discussion.
Subject: Re: [389-devel] plugin PRE_ENTRY_FN scope
On 01/17/2014 11:20 AM, Deas, Jim wrote:
Should I be able to use SLAPI_SEARCH_ATTR to view attributes about to
be returned to the client in PRE_ENTRY_FN?
Yes, looks like it, but you have to be prepared for the case where a client does not
specify a search attribute list - in this case, the client is asking for all
non-operational attributes in the entry.
Can I start a new search inside PRE_ENTRY_FN to find values needed
to augment the existing attributes being returned?
Yes, that should work. However, doing this parsing and internal search for every single
entry returned might be a big performance hit. You might want to examine the
SLAPI_SEARCH_ATTRS and do the internal search in a SLAPI_PLUGIN_PRE_SEARCH_FN, then store
the results in the operation (in an operation extension), then just use those results in
your PRE_ENTRY_FN. This is what the deref plugin does.
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
1:50 p.m.
New subject: plugin PRE_ENTRY_FN scope
On 01/17/2014 12:02 PM, Deas, Jim wrote:
Rich,
Thanks so much!
Are you suggesting I do an internal search in PRE_SARCH_FN
Yes.
then use the return to modify the original search request to include
additional items before allowing the original client search to begin?
You could do that too, but what you really want to do is, in your
PRE_ENTRY_FN, is to replace, in each entry returned, the memberuid
attribute values that start with "@", with the actual members of the group.
-----Original Message-----
From: 389-devel-bounces(a)lists.fedoraproject.org
[mailto:389-devel-bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Friday, January 17, 2014 10:32 AM
To: 389 Directory server developer discussion.
Subject: Re: [389-devel] plugin PRE_ENTRY_FN scope
On 01/17/2014 11:20 AM, Deas, Jim wrote:
> Should I be able to use SLAPI_SEARCH_ATTR to view attributes about to be returned to
the client in PRE_ENTRY_FN?
Yes, looks like it, but you have to be prepared for the case where a client does not
specify a search attribute list - in this case, the client is asking for all
non-operational attributes in the entry.
> Can I start a new search inside PRE_ENTRY_FN to find values needed to augment the
existing attributes being returned?
Yes, that should work. However, doing this parsing and internal search for every single
entry returned might be a big performance hit. You might want to examine the
SLAPI_SEARCH_ATTRS and do the internal search in a SLAPI_PLUGIN_PRE_SEARCH_FN, then store
the results in the operation (in an operation extension), then just use those results in
your PRE_ENTRY_FN. This is what the deref plugin does.
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
3745
days inactive
3746
days old
389-devel@lists.fedoraproject.org
11 comments
3 participants
participants (3)
-
Deas, Jim -
Nathan Kinder -
Rich Megginson