Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
22 of 22

LDAP lib throws exception when starting ESP

Fixed

Description

My ESP cannot be started when the LDAP security enabled. By tracing into the code, I found that an exception is thrown when the manager.addResources() is called inside the authmap.cpp. 

, 

Conclusion

None
Pinned fields
Click on the next to a field label to start pinning.

Details

Components

Assignee

Reporter

Priority

Compatibility

Point

Fix versions

Pull Request URL

https://github.com/hpcc-systems/HPCC-Platform/pull/14834

Roadmap

Not applicable

Affects versions

Created April 2, 2021 at 5:34 PM
Updated April 15, 2021 at 3:36 PM
Resolved April 15, 2021 at 3:36 PM

Activity

Show:

Kanghua Wang April 5, 2021 at 12:17 PM

For LDAP security, there is a systemUser setting in esp xml.

Tim Klemm April 2, 2021 at 9:28 PM

Considering these adds are in response to service load, and not attributable to a user, you either have to allow no user or require a system user just to start.

Kanghua Wang April 2, 2021 at 8:59 PM

Should we allow an empty user as the input of the addResources()? I think that ldap server has to log who adds the resource. 

Tim Klemm April 2, 2021 at 6:41 PM

More precisely, the auth map dereferences a NULL pointer for the ISecUser parameter of addResources and the exception appears to be caused by this. I saw this error last year with my external plugin and after confirming that every other parameter was valid and knowing that my manager's implementation of addResources was empty, the only thing left was dereferenced NULL pointer. I never identified which change caused the exception to start occurring, but one day it worked and the next it didn't and I'm not convinced that dereferencing NULL is supposed to work.

In my case, because addResources does nothing, I was able to get around the problem by removing the auth map call. Since LDAP does use the resource data, there are a couple options for fixing the problem. One would be to change the ISecManager interface to provide an addResources method that accepts ISecUser* instead of ISecUser&, effectively breaking all plugins.  Another, which would be my preference, would be for the manager to use internal methods to process the resources as they are created instead of expecting the auth map to pass everything created by the manager to the manager so the manager can know what the manager has created. 

Kanghua Wang April 2, 2021 at 5:37 PM

Similar issue is also found when the secmgr->addResourcesEx() is called in the 
Cws_accessEx::onResourceAdd().

Flag notifications