php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77806 Effective rights control attributes
Submitted: 2019-03-27 12:55 UTC Modified: -
From: alec@php.net Assigned:
Status: Open Package: LDAP related
PHP Version: 7.3.3 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: alec@php.net
New email:
PHP Version: OS:

 

 [2019-03-27 12:55 UTC] alec@php.net
Description:
------------
I'm using PHP 7.3.3-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Mar  7 2019 20:31:49) ( NTS )

See the sample script below. If I replace the attributes argument in ldap_search() call with ["*"] I get the expected result.

So, it looks like the attributes argument limits the attributes considered by the effective rights control. This is unexpected. I expected to limit only result attributes of the ldap entry, but not for the server control. Is there a way to set attributes=* for the control and keep attributes=['entryLevelRights', 'attributeLevelRights'] for the search result?

This might be a bug or feature request. Or maybe I don't understand ldap and effective rights control internals and this is impossible.

Test script:
---------------
$dn = 'ou=Groups,dc=example,dc=org';
$bind_dn = 'cn=Directory Manager';
$conn = ldap_connect('ldap://192.168.56.101:389');
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($conn, $bind_dn, 'password');

$result = ldap_search($conn, $dn, '(objectclass=*)',
    ['entryLevelRights', 'attributeLevelRights'],
    0, -1, -1, LDAP_DEREF_NEVER, [
        ['oid' => "1.3.6.1.4.1.42.2.27.9.5.2", 'value' => "dn:$bind_dn"]
    ]);

$entry = ldap_get_attributes($conn, ldap_first_entry($conn, $result));

echo $entry['attributeLevelRights'][0];

Expected result:
----------------
Something like:

objectClass:rscwo, aci:rscwo, ou:rscwo, businessCategory:rscwo, description:rscwo, destinationIndicator:rscwo, facsimileTelephoneNumber:rscwo, internationalISDNNumber:rscwo, l:rscwo, physicalDeliveryOfficeName:rscwo, postalAddress:rscwo, postalCode:rscwo, postOfficeBox:rscwo, preferredDeliveryMethod:rscwo, registeredAddress:rscwo, searchGuide:rscwo, seeAlso:rscwo, st:rscwo, street:rscwo, telephoneNumber:rscwo, teletexTerminalIdentifier:rscwo, telexNumber:rscwo, userPassword:rscwo, x121Address:rscwo

Actual result:
--------------
entrylevelrights:none, attributelevelrights:none

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-03-22 11:21 UTC] mcmic@php.net
Hello,

This is hard to answer as I do not know this control and never used it.

All I can say is that it seems its value should be BER-encoded in the request,
and that the attributes passed to ldap_search are just sent to the LDAP server as part of the SEARCH request.

I read section 9 of https://tools.ietf.org/html/draft-ietf-ldapext-acl-model-08 but I do not understand the part about response data.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 19:01:29 2024 UTC