389ds and Get Effective Rights control: neither entryLevelRights nor attributeLevelRights returned

[Graham Leggett]

Hi all,

After adding the Get Effective Rights control to some java code as follows, everything is
worked as before, except neither the entryLevelRights nor the attributeLevelRights
attributes are returned to me.

389-ds-base-1.2.11.15-97.el6_10.x86_64 is logging the following, which looks hopeful:

[18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 SRCH base="dc=x,dc=x,dc=x"
scope=2 filter="(&(objectClass=mailRec
ipient)(mail=mail(a)example.com))" attrs="* entrylevelrights attributelevelrights
aci" authzid="mail=minfrin(a)example.com,ou=
external,dc=x,dc=x,dc=x"
[18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 RESULT err=0 tag=101 nentries=1 etime=0 -
entryLevelRights: vadn

However neither the entrylevelrights nor the attributelevelrights attributes are being
returned in the response, and I have run out of ideas - what am I missing?

The java code to add the control is as follows:

			BerByteArrayOutputStream berStream = new BerByteArrayOutputStream(
					dn.length() + 50, true);
			BerOctetString berString = new BerOctetString(
					("dn:" + dn).getBytes());
			berString.encode(berStream, true);
			berStream.close();

			List<Control> controls = new ArrayList<Control>(Arrays.asList(ctx
					.getRequestControls()));
			controls.add(new BasicControl("1.3.6.1.4.1.42.2.27.9.5.2", true,
					berStream.getArray()));
			ctx.setRequestControls(controls.toArray(new Control[controls.size()]));

Regards,
Graham
—

[William Brown]

>  On 18 Nov 2019, at 09:27, Graham Leggett <minfrin(a)sharp.fm&gt;
> wrote:
>  
>  Hi all,
>  
>  After adding the Get Effective Rights control to some java code as follows, everything is
> worked as before, except neither the entryLevelRights nor the attributeLevelRights
> attributes are returned to me.
>  
>  389-ds-base-1.2.11.15-97.el6_10.x86_64 is logging the following, which looks hopeful:
>  
>  [18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 SRCH base="dc=x,dc=x,dc=x"
> scope=2 filter="(&(objectClass=mailRec
>  ipient)(mail=mail(a)example.com))&quot; attrs="* entrylevelrights attributelevelrights
> aci" authzid=&quot;mail=minfrin(a)example.com,ou=
>  external,dc=x,dc=x,dc=x"
>  [18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 RESULT err=0 tag=101 nentries=1 etime=0 -
> entryLevelRights: vadn
>  
>  However neither the entrylevelrights nor the attributelevelrights attributes are being
> returned in the response, and I have run out of ideas - what am I missing?
>  
>  The java code to add the control is as follows:
>  
>  			BerByteArrayOutputStream berStream = new BerByteArrayOutputStream(
>  					dn.length() + 50, true);
>  			BerOctetString berString = new BerOctetString(
>  					("dn:" + dn).getBytes());
>  			berString.encode(berStream, true);
>  			berStream.close();
>  
>  			List<Control> controls = new ArrayList<Control>(Arrays.asList(ctx
>  					.getRequestControls()));
>  			controls.add(new BasicControl("1.3.6.1.4.1.42.2.27.9.5.2", true,
>  					berStream.getArray()));
>  			ctx.setRequestControls(controls.toArray(new Control[controls.size()]));
>   
As I'm sure you're aware, the docs are here:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...

I think you don't need to request the entrylevelrights or attributelevelrights on the
search (the log looks like you're requesting them). You probably just want * or + here
instead.

Otherwise I'm not 100% sure here. Perhaps the best thing is actually to attach gdb to
the server and break on:

br _ger_parse_control 

And then step through with: "next" to see what logic paths are being taken on
the dn parser - or if you even reach that stage.

You could alternately break on acl_get_effective_rights to see the full extended op
processing logic too. 

Sorry I can't give a more concrete piece of advice here :( 

>  Regards,
>  Graham
>  —
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Graham Leggett]

On 18 Nov 2019, at 01:19, William Brown <wbrown(a)suse.de&gt; wrote:

>  As I'm sure you're aware, the docs are here:
>  
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>  
>  I think you don't need to request the entrylevelrights or attributelevelrights on the
> search (the log looks like you're requesting them). You probably just want * or + here
> instead. 
I tried that, but it made no difference. I also noticed that despite asking for attributes
“*” and “+”, the java code didn’t give me any operational attributes back at all.

I’m assuming that entryLevelRights/attributeLevelRights are operational attributes and
389ds won’t return them with a “*” attribute on it’s own?

I’m trying to work out whether this is a java issue or a 389ds issue.

Are there any known issues when trying to return operational attributes from 389ds to java
JNDI calls?

>  Otherwise I'm not 100% sure here. Perhaps the best thing is
> actually to attach gdb to the server and break on:
>  
>  br _ger_parse_control 
>  
>  And then step through with: "next" to see what logic paths are being taken on
> the dn parser - or if you even reach that stage.
>  
>  You could alternately break on acl_get_effective_rights to see the full extended op
> processing logic too. 
>  
>  Sorry I can't give a more concrete piece of advice here :(  
gdb stops on these breakpoints, so the logic is definitely triggered, although I don't
have any debuginfos configured to step through the code. Let me dig further on this.

Regards,
Graham
—

[William Brown]

>  On 18 Nov 2019, at 10:09, Graham Leggett <minfrin(a)sharp.fm&gt;
> wrote:
>  
>  On 18 Nov 2019, at 01:19, William Brown <wbrown(a)suse.de&gt; wrote:
>  
> > As I'm sure you're aware, the docs are here:
> > 
> >
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
> > 
> > I think you don't need to request the entrylevelrights or attributelevelrights on
> the search (the log looks like you're requesting them). You probably just want * or +
> here instead.
>  
>  I tried that, but it made no difference. I also noticed that despite asking for
> attributes “*” and “+”, the java code didn’t give me any operational attributes back at
> all.
>  
>  I’m assuming that entryLevelRights/attributeLevelRights are operational attributes and
> 389ds won’t return them with a “*” attribute on it’s own? 
The attributes you "request" are the attributes it will do an effective rights
check on, and the server just "puts" the *rights attributes in your response
without asking (well, you did ask because of the control)

>  
>  I’m trying to work out whether this is a java issue or a 389ds issue. 
Why not both?

>  
>  Are there any known issues when trying to return operational attributes from 389ds to
> java JNDI calls? 
Controls and extended ops are difficult to get right at the best of times - I had to do so
recently with python for something and it was a few days of hair tearing. So the error
could be ... anywhere.

>  
> > Otherwise I'm not 100% sure here. Perhaps the best thing is actually to attach
> gdb to the server and break on:
> > 
> > br _ger_parse_control 
> > 
> > And then step through with: "next" to see what logic paths are being taken
> on the dn parser - or if you even reach that stage.
> > 
> > You could alternately break on acl_get_effective_rights to see the full extended op
> processing logic too. 
> > 
> > Sorry I can't give a more concrete piece of advice here :( 
>  
>  gdb stops on these breakpoints, so the logic is definitely triggered, although I
> don't have any debuginfos configured to step through the code. Let me dig further on
> this. 
If you are on RH/Fedora, it will issue you a command such as "missing debuginfo
....." and a command you can run to install them :) 

>  
>  Regards,
>  Graham
>  —
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Graham Leggett]

On 18 Nov 2019, at 03:05, William Brown <wbrown(a)suse.de&gt; wrote:

> > I tried that, but it made no difference. I also noticed that
> despite asking for attributes “*” and “+”, the java code didn’t give me any operational
> attributes back at all.
> > 
> > I’m assuming that entryLevelRights/attributeLevelRights are operational attributes
> and 389ds won’t return them with a “*” attribute on it’s own?
>  
>  The attributes you "request" are the attributes it will do an effective rights
> check on, and the server just "puts" the *rights attributes in your response
> without asking (well, you did ask because of the control)
>  
> > 
> > I’m trying to work out whether this is a java issue or a 389ds issue.
>  
>  Why not both? 
Possibly - I eventually found that elsewhere in my code I was silently stripping any
attribute that came back that didn’t have a schema, and these explained why
entryLevelRights/attributeLevelRights were missing, but not why operational attributes had
no schemas.

This leads to the issue of how do we find the syntax OIDs for operational attributes? Are
these made available by 389ds in some way, or does the calling code have to know how to
handle each type of operational attribute?

Regards,
Graham
—

[William Brown]

>  On 18 Nov 2019, at 22:27, Graham Leggett <minfrin(a)sharp.fm&gt;
> wrote:
>  
>  On 18 Nov 2019, at 03:05, William Brown <wbrown(a)suse.de&gt; wrote:
>  
> >> I tried that, but it made no difference. I also noticed that despite asking for
> attributes “*” and “+”, the java code didn’t give me any operational attributes back at
> all.
> >> 
> >> I’m assuming that entryLevelRights/attributeLevelRights are operational
> attributes and 389ds won’t return them with a “*” attribute on it’s own?
> > 
> > The attributes you "request" are the attributes it will do an effective
> rights check on, and the server just "puts" the *rights attributes in your
> response without asking (well, you did ask because of the control)
> > 
> >> 
> >> I’m trying to work out whether this is a java issue or a 389ds issue.
> > 
> > Why not both?
>  
>  Possibly - I eventually found that elsewhere in my code I was silently stripping any
> attribute that came back that didn’t have a schema, and these explained why
> entryLevelRights/attributeLevelRights were missing, but not why operational attributes had
> no schemas.
>  
>  This leads to the issue of how do we find the syntax OIDs for operational attributes? Are
> these made available by 389ds in some way, or does the calling code have to know how to
> handle each type of operational attribute? 
You should be able to search and parse cn=schema remotely to see what the server is
offering attribute type wise

>  
>  Regards,
>  Graham
>  —
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs