Univention Bugzilla – Bug 41109
users/user: manually set uidNumber should not be written into univentionLastUsedValue
Last modified: 2019-03-06 17:25:09 CET
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
There is a Customer ID set so I set the flag "Enterprise Customer affected".
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.
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.
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.
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
(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)?
(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.
(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
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.
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.
<http://errata.software-univention.de/ucs/4.3/252.html>