Bug 45052 - user should not be removeable from its primary group
user should not be removeable from its primary group
Status: NEW
Product: UCS
Classification: Unclassified
Component: UMC - Groups
UCS 4.2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
UMC maintainers
:
: 27160 45053 (view as bug list)
Depends on:
Blocks: 45053
  Show dependency treegraph
 
Reported: 2017-07-21 15:02 CEST by Nico Stöckigt
Modified: 2018-05-16 17:56 CEST (History)
5 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.069
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number: 2017071221000724, 2012051021001383
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Stöckigt univentionstaff 2017-07-21 15:02:36 CEST
A user 'userA' with primaryGroup 'GroupX' is _allways_ member of this group. In openLDAP 'userA' is also added to this group via 'memberUid' and 'uniqueMember'. When you remove 'userA' from 'groupX' the primaryGroup of 'userA' is not touched - he still has primaryGroup 'groupX' and due to that is effectively member of this group. It seems to doesn't make sense to be able to remove the mapping of an user from it's primaryGroup. At least in UMC the user should be grayed out and not removeable.
Comment 1 Florian Best univentionstaff 2017-07-21 15:19:20 CEST
So basically you want that the following modification is not possible anymore:

# udm users/user create --set username=foo --set lastname=foo --set password=univention --set primaryGroup="cn=Domain Users,cn=groups,$(ucr get ldap/base)"
Object created: uid=foo,dc=school,dc=local
# udm groups/group modify --dn "cn=Domain Users,cn=groups,$(ucr get ldap/base)" --remove users="uid=foo,$(ucr get ldap/base)"
Object modified: cn=Domain Users,cn=groups,dc=school,dc=local
Comment 2 Florian Best univentionstaff 2017-07-21 15:30:14 CEST
Can you describe what the effects are if such a user exists?
Comment 3 Florian Best univentionstaff 2017-07-21 15:30:37 CEST
*** Bug 45053 has been marked as a duplicate of this bug. ***
Comment 4 Nico Stöckigt univentionstaff 2017-07-24 09:04:15 CEST
(In reply to Florian Best from comment #1)
> So basically you want that the following modification is not possible
> anymore:
> 
> # udm users/user create --set username=foo --set lastname=foo --set
> password=univention --set primaryGroup="cn=Domain Users,cn=groups,$(ucr get
> ldap/base)"
> Object created: uid=foo,dc=school,dc=local
> # udm groups/group modify --dn "cn=Domain Users,cn=groups,$(ucr get
> ldap/base)" --remove users="uid=foo,$(ucr get ldap/base)"
> Object modified: cn=Domain Users,cn=groups,dc=school,dc=local

imho there is a difference between UMC and udm(-cli); UMC users probably not as advanced as udm users, therefor the possibility to perform the udm action should not be restricted due to there might be situations where it totally makes sense to remove a user entry from a group - even when the primaryGroup of the user is left untouched.
Comment 5 Nico Stöckigt univentionstaff 2017-07-24 09:23:14 CEST
(In reply to Florian Best from comment #2)
> Can you describe what the effects are if such a user exists?

It's quite confusing when the user is no longer member in it's primaryGroup but (of course) still has all the privileges due to the gidNumber is still the same as before.
Also the connector skips to add a user to the specific group when it already is the users primaryGroup. This seems not to be a consistent behavior (but it's MS/AD standard), at least it is confusing too. If I'm wrong please point me to the right direction.
Comment 6 Florian Best univentionstaff 2018-01-31 13:40:43 CET
I once added a test case for this.
r76583 | Bug #27160: add test case for bug
Comment 7 Florian Best univentionstaff 2018-01-31 13:41:04 CET
*** Bug 27160 has been marked as a duplicate of this bug. ***
Comment 8 Stefan Gohmann univentionstaff 2018-03-15 06:32:34 CET
Move to 4.3-0-errata. If a UCS 4.2 backport is needed, please clone this issue.