Issue 7495 - access filter not correctly validated if assertion attribute not requested
Summary: access filter not correctly validated if assertion attribute not requested
Status: VERIFIED FEEDBACK
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-17 09:00 UTC by Michael Ströder
Modified: 2021-08-03 18:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Michael Ströder 2013-01-17 09:00:13 UTC
Full_Name: Michael Str�der
Version: RE24 6f33e2c
OS: Debian Squeeze
URL: 
Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f)


This is tested with RE24 built for Debian Squeeze:
It seems that ACLs are not correctly evaluated when processing a search request
if the assertion type is not requested in the search request.

Example:

access to
  dn.subtree="o=example"
  attrs=sambaNTPassword
  filter="(organizationalStatus=0)"
    by group="uid=samba_dc,o=example" write
    by group="cn=slapd Admins,ou=groups,o=example" =sw
    by self =w
    by * none

The following search correctly returns attribute sambaNTPassword of the entry:

ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" organizationalStatus
sambaNTPassword

But this search does not return sambaNTPassword:

ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword

I cannot find any hint in slapd.access(5) that this is expected behaviour.
Comment 1 Michael Ströder 2013-01-17 10:51:47 UTC
Sorry for the confusion caused by editing what I've copied from the real
system before which uses a group for several Samba DC instances.

In this example the ACL part should be more simple like this:

access to
  dn.subtree="o=example"
  attrs=sambaNTPassword
  filter="(organizationalStatus=0)"
    by dn.exact="uid=samba_dc,o=example" write
    by group="cn=slapd Admins,ou=groups,o=example" =sw
    by self =w
    by * none

Ciao, Michael.

Comment 2 Hallvard Furuseth 2013-01-17 23:44:58 UTC
Cannot reproduce on RedHat Linux, x86_64.  But then, the info was
rather brief. (E.g. which backend? Was that a per-backend or global
ACL? Might some overlays or other access statements interefere?)

Anyway, please provide a complete config and preferably LDIF which
demonstrates the problem.
Comment 3 Michael Ströder 2013-01-18 09:50:10 UTC
Hallvard B Furuseth wrote:
> Cannot reproduce on RedHat Linux, x86_64.  But then, the info was
> rather brief. (E.g. which backend? Was that a per-backend or global
> ACL? Might some overlays or other access statements interefere?)
> 
> Anyway, please provide a complete config and preferably LDIF which
> demonstrates the problem.

Thanks for looking it this.

As usual this is a more complex customer setup with many ACLs and several
overlays. I tried to provide a simple example but I also see that this does
not show the issue on my local machine.

I will try to strip down the complex config. But this will take a while.

Ciao, Michael.


Comment 4 Hallvard Furuseth 2013-01-21 12:49:02 UTC
changed state Open to Feedback
moved from Incoming to Software Bugs
Comment 5 Hallvard Furuseth 2013-01-21 14:09:43 UTC
Try to put organizationalStatus in olcExtraAttrs aka extra_attrs.
Though ITS#7422 says that does not always work either.

The doc should mention extra_attrs in places like 'filter' in
slapd.access(5), since people who don't read the entire config
manpage may not know to look for this option otherwise.
Comment 6 Michael Ströder 2013-01-23 19:13:12 UTC
Using extra_attrs would be a possible work-around (tested).

Unfortunately it seems to trigger a seg fault in slapo-rwm in my setup which
is hard to track down to a certain cause. slapd starts ok but quite soon a seg
fault message is written to syslog. Just before the seg fault I see the usual
search requests of sssd in the logs...

Ciao, Michael.