Knowing that the first issue is 'working as designed', I can now focus on 
exactly how to fix it. In my case, the issue is that a vendor's code is 
appending "name=..." to its search filter to find a user group.

Thanks, I can troubleshoot the second issue, it isn't a roadblock to my task.

On 05/21/2015 07:50 AM, Martin Kosek wrote:
> On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote:
>> Still the behavior of returning nothing by adding an extra false 
>> term,
> IIRC, this is done on purpose, there was an CVE and as a fix, if you 
> are querying with an attribute you do not have permission to query 
> with, you get no answers.
correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508
and behaviour matches the spec in 13.3.3.3: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions

For the other problem, there  is not enough information to judge. If two 
entries are in different subtrees also different acis could apply, we need the 
full set of acis, the full search and eventuallay access control logging 
(nsslapd-errorlog-level: 128)


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to