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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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: Tue Oct 15 13:01:27 2024 UTC