The regular coverity scans reveal potential issues. This ticket should be used to track patches addressing these issues
15144 fix <img alt="0001-Coverity-15144.patch" src="/389-ds-base/issue/raw/0ef353c750bc00825b181e899b85cc0a68d1a35285aedd3f2bd27ac1f6bb6c05-0001-Coverity-15144.patch" />
Metadata Update from @tbordaz: - Custom field type adjusted to defect
15145 fix
<img alt="0001-Coverity-15145.patch" src="/389-ds-base/issue/raw/c234ed4f28740b8b95312966c725dce054958a665097810debc02fe0950826bb-0001-Coverity-15145.patch" />
ack 15144
15145 has a problem. I think in this case, any SIMPLE bind will map to anonymous rather than a user. I think that there are two options.
Hope that helps,
@firstyear thanks for the reviews. Regarding 15145: cred is NULL when if condition is evaluated. This part of code is evaluated in autobind where cred/sdn are NULL. It has been checked few lines before
if (pb_sdn != NULL || cred != NULL) { return LDAP_OPERATIONS_ERROR; }
The issue reported by coverity is that "cred->bv_len == 0" component is dead code as "cred==NULL" is always true at this line
15146 and 15147 fixes <img alt="0001-Coverity-15146-and-15147.patch" src="/389-ds-base/issue/raw/19b65dcb7f9a37d272190bd34255b6b526846a0c58772eef9bfe0d0da85e9b20-0001-Coverity-15146-and-15147.patch" />
Indeed you are correct. In that case, you should probably make the check:
if (method == LDAP_AUTH_SIMPLE && cred->bv_len == 0) { return SLAPI_BIND_ANONYMOUS; }
I think.
What is the problem with 15146 and 15147? I think to get here op and conn must be != NULL. ...
Indeed you are correct. In that case, you should probably make the check: if (method == LDAP_AUTH_SIMPLE && cred->bv_len == 0) { return SLAPI_BIND_ANONYMOUS; } I think. since we know cred==NULL dereferencing it would be a bad idea
Indeed you are correct. In that case, you should probably make the check: if (method == LDAP_AUTH_SIMPLE && cred->bv_len == 0) { return SLAPI_BIND_ANONYMOUS; }
I think. since we know cred==NULL dereferencing it would be a bad idea
The problem is that those local variables are taken from pblock and coverity believe there is a chance they are NULL from the pblock. I agree it is 'False positive' condition and could be sort out this way in that coverity report. A pending question is: will this same error be reported again in a Future coverity report ? So to definitely fix those 'False positive' we can add those tests.
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field version adjusted to None - Issue set to the milestone: 1.3.7.0
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2385
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Log in to comment on this ticket.