samba - Nov 2023 - LDAP_MATCHING_RULE_IN_CHAIN no longer working after upgrade?

On Wed, 2023-11-22 at 00:07 +0000, Jonathan Hunter via samba
wrote:
> Hi Andrew
> On Fri, 10 Nov 2023 at 15:50, Jonathan Hunter <jmhunter1 at
gmail.com>
> wrote:
> > 0776ce5caedf18aa8cc1d1dddb1a425f3d0c926c is the first bad
> > commitcommit 0776ce5caedf18aa8cc1d1dddb1a425f3d0c926c   CVE-2023-
> > 0614 lib/ldb-samba Ensure ACLs are evaluated
> > onSAMBA_LDAP_MATCH_RULE_TRANSITIVE_EVAL /
> > LDAP_MATCHING_RULE_IN_CHAIN
> > I've created a bug for this in bugzilla, hope that's helpful:
> > https://bugzilla.samba.org/show_bug.cgi?id=15515
> 
> Is there anything I can do to help with this?
> Looking through git changes, I found this commit with the same
> commitmessage as returned by my 'git bisect' (I am not sure why the
> commitIDs are different to the output of my 'git bisect'?), that
> looks likea very simple change:
>
https://gitlab.com/samba-team/samba/-/commit/dfe7b05730425e9f1b0616bb7757dbf77bae6cd2
> (if the view I get from gitlab is correct, it's a one-line change
> tolib/ldb-samba/ldb_matching_rules.c )
> I checked out revision samba-4.19.2 and reverted just this one
> linechange, and can confirm that my LDAP query works correctly again
> inthat scenario.
> I'm sure the fix isn't as simple as "revert the change",
as it
> wasadded for a reason - but it seems to have led to a regression for
> meand has broken my LDAP searches that use
> LDAP_MATCHING_RULE_IN_CHAIN.Is there any sensible route I can help
> move this forward?
Are you sure that the ACLs on all the items in the chain should allow
reading?
Andrew Bartlett-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead                https://catalyst.net.nz/services/samba
Catalyst.Net Ltd


Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group
company

Samba Development and Support: https://catalyst.net.nz/services/samba

Catalyst IT - Expert Open Source Solutions

On Wed, 22 Nov 2023 at 01:03, Andrew Bartlett <abartlet at samba.org>
wrote:
> Are you sure that the ACLs on all the items in the chain should allow
reading?
It's an excellent question, thank you - I'd like to just say
"Yes" but
I will certainly check, as it's of course possible that my domain was
misconfigured previously, and the change has in fact introduced
correct behaviour..

Am I right in thinking that the objects I need to look at are
- the group itself
- all (some?) members of the group
- any others?

Are permissions checked in a hiearchical fashion, i.e. if OU=myou does
not allow a particular user to read it, then would
CN=somegroup,OU=myou still be denied regardless of the explicit
permissions on the CN=somegroup,OU=myou object? And I believe I'm
correct in thinking that a user can be a member of a group, even
though that user might not have permission to read the group
themselves...?

Is there a programmatical way of viewing permissions on all these
objects, or am I best manually going through with the 'ldifde'
Windows tool (which I think is what I originally used to set the
permissions in the first place)?

Many thanks

Jonathan

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein