Bug 41109 - users/user: manually set uidNumber should not be written into univentionLastUsedValue
users/user: manually set uidNumber should not be written into univentionLastU...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.3-2-errata
Assigned To: Sönke Schwardt-Krummrich
Dirk Wiesenthal
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-25 10:23 CEST by Florian Best
Modified: 2019-03-06 17:25 CET (History)
8 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.171
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2016-04-25 10:23:48 CEST
Same for gidNumber, etc.

+++ This bug was initially created as a clone of Bug #20644 +++

Manuell gesetzte Benutzer-IDs sollten nicht in univentionLastUsedValue gespeichert werden, um ein unerwünschtes Zurücksetzen der Zählung und damit ein stilles Recycling freier uidNumber zu vermeiden. (Ticket#: 2010110810003228)

+++ This bug was initially created as a clone of Bug #20641 +++

Das hat auch einen nachhaltigen Effekt für weitere Benutzer die angelegt
werden, da die letzte verwendete Benutzer-ID im LDAP gespeichert wird und dann
der nächste Benutzer wohl die UID 102 erhalten wird:

dn: cn=uidNumber,cn=temporary,cn=univention,dc=ucs24amd64,dc=qa
cn: uidNumber
objectClass: top
objectClass: organizationalRole
objectClass: univentionLastUsed
univentionLastUsedValue: 101
Comment 1 Florian Best univentionstaff 2017-06-28 14:52:36 CEST
There is a Customer ID set so I set the flag "Enterprise Customer affected".
Comment 2 Jannik Ahlers univentionstaff 2018-01-08 15:43:05 CET
I could not reproduce the bug.
Even though values under 1000 get written to univentionLastUsedValue, it seems to have no effect on accounts created afterwards, as they get uids with values over 1000.
Comment 3 Florian Best univentionstaff 2018-01-10 14:43:31 CET
I think it is still wrong. When I create a user with no automatically created user id the value is stored in the univentionLastUsedValue of cn=uidNumber. This causes that if you create a user with uidNumber=1000001 you cannot create any more users.

root@master:~# univention-ldapsearch -LLL 'univentionLastUsedValue=*' univentionLastUsedValue              
dn: cn=gidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12862

dn: cn=uidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12890

root@master:~# udm users/user create --set username=foobar --set uidNumber=12900 --set password=univention --set lastname=foo
Object created: uid=foobar,dc=school,dc=local
root@master:~# univention-ldapsearch -LLL 'univentionLastUsedValue=*' univentionLastUsedValue              
dn: cn=gidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12862

dn: cn=uidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12900

                         ^^^^^ Wrong!  

root@master:~# udm users/user create --set username=foobar2 --set password=univention --set lastname=foo
Object created: uid=foobar2,dc=school,dc=local
root@master:~# univention-ldapsearch -LLL 'univentionLastUsedValue=*' univentionLastUsedValue              
dn: cn=gidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12862

dn: cn=uidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12901

root@master:~# udm users/user create --set username=foobar6 --set uidNumber=1000000 --set password=univention --set lastname=foo                                                                                                                                                 
Object created: uid=foobar6,dc=school,dc=local

root@master:~# udm users/user create --set username=foobar7 --set password=univention --set lastname=foo                                                                                                                                                                         
Object created: uid=foobar7,dc=school,dc=local

root@master:~# univention-ldapsearch -LLL 'univentionLastUsedValue=*' univentionLastUsedValue                                                                                                                                                                                    
dn: cn=gidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 12862

dn: cn=uidNumber,cn=temporary,cn=univention,dc=school,dc=local
univentionLastUsedValue: 1000001

root@master:~# udm users/user create --set username=foobar8 --set password=univention --set lastname=foo
E: Object exists: (nolock) The attribute 'uidNumber' could not get locked.
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2018-08-04 20:36:44 CEST
A school customer is affected that sets the uidNumber for new users during import (for previously removed/archived users). So the counter for uidNumber isn't monotonic increasing.
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2018-09-18 13:30:19 CEST
Normally, the value univentionLastUsedValue for uidNumber and gidNumber
increases automatically and monotonously when creating new users/groups.
The value was saved in LDAP to optimize the search for a free UID/GID number.

However, a smaller value was saved in LDAP if a smaller value for
uidNumber/gidNumber was explicitly specified when creating a user/group
(in short: the last value used was always saved).
This could mean that the next used UID/GID numbers were smaller than the
largest UID/GID number assigned so far. The numbers were reused if they
were free. This caused problems in some environments.

Therefore, the behavior is changed so that the last used value
is only stored in LDAP if the uidNumber/gidNumber was determined 
automatically and NOT specified manually.

Package: ucs-test
Version: 8.0.28-189A~4.3.0.201809181317
Branch: ucs_4.3-0
Scope: errata4.3-2

Package: univention-directory-manager-modules
Version: 13.0.23-1A~4.3.0.201809181315
Branch: ucs_4.3-0
Scope: errata4.3-2

974ec4d837 Bug #41109: add execution flag for 38_user_univentionLastUsedValue
1325d2367a Bug #41109: Merge branch 'sschwardt/41109/432/uidNumber-lastUsedValue' into 4.3-2
b432b61685 Bug #41109: add changelog entry
b04b62eb9c Bug #41109: add 3 new tests for checking the handling of univentionLastUsedValue
72104227f5 Bug #41109: add advisory
b58de10691 Bug #41109: add changelog entry
4ec2fda901 Bug #41109: do not always update univentionLastUsedValue for uidNumber
Comment 6 Daniel Tröder univentionstaff 2018-09-18 13:44:30 CEST
(In reply to Sönke Schwardt-Krummrich from comment #5)
> Normally, the value univentionLastUsedValue for uidNumber and gidNumber
> increases automatically and monotonously when creating new users/groups.
> The value was saved in LDAP to optimize the search for a free UID/GID number.
> 
> However, a smaller value was saved in LDAP if a smaller value for
> uidNumber/gidNumber was explicitly specified when creating a user/group
> (in short: the last value used was always saved).
> This could mean that the next used UID/GID numbers were smaller than the
> largest UID/GID number assigned so far. The numbers were reused if they
> were free. This caused problems in some environments.
> 
> Therefore, the behavior is changed so that the last used value
> is only stored in LDAP if the uidNumber/gidNumber was determined 
> automatically and NOT specified manually.
Hmm - wouldn't that be a problem if the explicitly specified UID/GID number is _higher_ than the value for univentionLastUsedValue saved in LDAP?
Then the mentioned problem can occur later.

Shouldn't the criteria for when to update univentionLastUsedValue be "if the used UID/GID number is higher than the current one" (and not whether it was set manually)?
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2018-09-19 09:10:20 CEST
(In reply to Daniel Tröder from comment #6)
> > Therefore, the behavior is changed so that the last used value
> > is only stored in LDAP if the uidNumber/gidNumber was determined 
> > automatically and NOT specified manually.
>
> Hmm - wouldn't that be a problem if the explicitly specified UID/GID number
> is _higher_ than the value for univentionLastUsedValue saved in LDAP?
> Then the mentioned problem can occur later.

No. univentionLastUsedValue is only used as a starting point for the search for a free uidNumber/gidNumber and is an optimization so that the search does not always start at 1 and then x LDAP queries have to be made to find a free uidNumber/gidNumber.

If a uidNumber greater than univentionLastUsedValue is specified manually, the manually specified value is NOT stored in univentionLastUsedValue and subsequent users/groups continue to receive their uidNumber/gidNumber sequentially. The mechanism then automatically skips the manually assigned uidNumber/gidNumber.
This behavior was already like this before and is nothing new.

In the customer scenarios, the point is that previously assigned uidNumbers should later be reused for the same user if the user is created again because it was temporarily deleted. In a scenario where uidNumbers are to be set completely "randomly", the uidNumbers must either be specified manually by each user when creating them or univentionLastUsedValue must be set to a very high value beforehand in order to avoid any conflict within a certain uidNumber/gidNumber range.
Comment 8 Daniel Tröder univentionstaff 2018-09-19 09:53:56 CEST
(In reply to Sönke Schwardt-Krummrich from comment #7)
> In the customer scenarios, the point is that previously assigned uidNumbers
> should later be reused for the same user if the user is created again
> because it was temporarily deleted.
That's what I mean. Example:

1. univentionLastUsedValue = 10000
2. new user ('joe') created with uidNumber = 10002
→ univentionLastUsedValue not changed
3. 'joe' is deleted
4. two new users are created without manually specifying a uidNumber
→ 10002 is used
Comment 9 Daniel Tröder univentionstaff 2018-09-19 11:19:21 CEST
As discussed, while both variants are not complete solutions for the customers scenario (she must manually raise univentionLastUsedValue above all manually used uidNumbers), the Sönkes implementation has no side effects. While my proposal might evade a few more situations, it may require further work to for example handle the raised probability of max-uid situations. So let's keep his solution.
Comment 10 Dirk Wiesenthal univentionstaff 2018-09-19 16:54:52 CEST
Ok, works.

56_all_roles_univentionLastUsedValue failed in my tests, but this seems to be a local issue. ("Default primary group does not exist: cn=Windows Hosts,cn=groups,dc=sparka-43,dc=intranet")

As they pass in the nightly tests, I think it is okay.
Comment 11 Erik Damrose univentionstaff 2018-09-26 13:24:28 CEST
<http://errata.software-univention.de/ucs/4.3/252.html>