Bug 53541 – UDM locking is done with ldap connection from user, which cannot see every object

Bug 53541 - UDM locking is done with ldap connection from user, which cannot see every object


Summary:	UDM locking is done with ldap connection from user, which cannot see every ob...

Status:	NEW

Product:	UCS
Classification:	Unclassified
Component:	UDM (Generic)
Version:	UCS 5.0
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	UMC maintainers
QA Contact:	UMC maintainers

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2021-07-02 12:04 CEST by Florian Best
Modified:	2021-09-08 14:38 CEST (History)
CC List:	0 users

See Also:
What kind of report is it?:	Development Internal
What type of bug is this?:	---
Who will be affected by this bug?:	---
How will those affected feel about the bug?:	---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Florian Best

2021-07-02 12:04:20 CEST

The locking of attributes (e.g. to check the uniqueness of uid/uidNumber/gidNumber/etc.) is currently done with the permissions of the user doing the operation.

If there are ACL's which prevent reading any user/group/etc object the ldap search checking for uniqueness will fail and therefore UDM allows to use a unique attribute twice.

In general modifications are done with Domain Admin account, which see everything.

In UCS@school each school user and each machine-account is limited to its own school, other objects are therefore hidden.

We should:
1. additionally to UDM try to use the unique constraint in the slapd.conf
2. do the lock() searches with cn=admin (not cn=machine$!)
3. probably we should also do the lock() modifications with cn=admin, so that we don't always need to specify extra LDAP ACL's for this use case (e.g. in UCS@school or multi-tenant scenarios) !?!