Univention Bugzilla – Bug 36210
Handling of userexpiry is unexact
Last modified: 2020-07-13 11:14:34 CEST
The users/user module reads the shadowExpire value (days since 1970-01-01) from LDAP and converts the value to a ISO datestring using UTC as reference timezone before storing it in self.info['userexpiry']. The code for handling changes of self.info['userexpiry'] expects a german date string ('16.10.14') and converts the value into days since 1970-01-01 using local timezone and some hardcoded offset (+1) which results in off-by-one errors for the shadowExpire value depending on the local timezone. If a timezone with negative offset (like EDT == -0400) is used, the value stored in LDAP is one day greater than the specified value/datestring.
Please also check if there are similar timezone problems with the passwordexpiry property. And recheck the ucs-test scripts 25_script_lock_expired_accounts and 25_script_lock_expired_passwords.
Created attachment 7745 [details] OpenLDAP access.log Currently <http://jenkins.knut.univention.de:8080/job/UCS-4.1/job/UCS-4.1-2/job/AutotestJoin/lastCompletedBuild/SambaVersion=s4,Systemrolle=backup/testReport/junit/61_udm-users/26_password_expire_date/test/> fails since several days. This is caused by something(most probably the S4C) modifying the password expiration date in some strange way: If that modifications happens fast enough, the test success, otherwise it fails. I can trigger it by hand doing: # udm users/user create --set username=dejavu --set locked=none --set lastname=pc3xaf9fwb --set userexpiry=2016-06-05 --position "cn=users,$(ucr get ldap/base)" --set password=univention # /usr/share/univention-directory-manager-tools/lock_expired_accounts --only-last-week -n Initializing... (Tue Jun 14 18:10:10 2016) ... # sleep 20 # /usr/share/univention-directory-manager-tools/lock_expired_accounts --only-last-week -n Initializing... (Tue Jun 14 18:10:23 2016) ... uid=dejgyanmmh expired at 2016-06-07 ... skipped due to dry run (expected modification: locked='posix') The OpenLDAP-access-log shows "shadowExpire" being modified +1 several times: $ grep shadowExpire ~/BUG/36210_udm-shadowExpire.log reqMod: shadowExpire:+ 16958 reqMod: shadowExpire:= 16959 reqMod: shadowExpire:= 16960 reqMod: shadowExpire:= 16961 reqMod: shadowExpire:= 16962 reqMod: shadowExpire:= 16963 reqMod: shadowExpire:= 16964 reqMod: shadowExpire:= 16965 reqMod: shadowExpire:= 16966 It keeps incrementing ever since: # univention-ldapsearch -LLLs base -b uid=dejavu,cn=users,dc=AutoTest091,dc=local shadowExpire dn: uid=dejavu,cn=users,dc=AutoTest091,dc=local shadowExpire: 17061 This may be caused by udm always adding one day on modifications: ./modules/univention/admin/handlers/users/user.py:2263 > shadowExpire="%d" % long(time.mktime(time.strptime(self['userexpiry'], "%Y-%m-%d"))/3600/24+1) The comment in management/univention-directory-manager-modules/scripts/lock_expired_account:84 is also wrong: > today = int(time.time() / 24 / 3600) # time.time() returns the local time time.time() returns the seconds since 1970-01-01T00:00:00 UTC, *not* local time $ (export TZ=UTC;date;date -d @$(python -c 'import time;print time.time()');date -d @0) Di 14. Jun 14:28:45 UTC 2016 Di 14. Jun 14:28:45 UTC 2016 Do 1. Jan 00:00:00 UTC 1970
Maybe important: The EC2 tests run in # cat /etc/timezone America/New_York # zdump America/New_York UTC Europe/Berlin America/New_York Tue Jun 14 18:34:47 2016 EDT UTC Tue Jun 14 22:34:47 2016 UTC Europe/Berlin Wed Jun 15 00:34:47 2016 CEST
(In reply to Philipp Hahn from comment #3) > Maybe important: The EC2 tests run in > # cat /etc/timezone > America/New_York Looks like a connector bug: >>> s42unix_time(unix2s4_time('2016-11-09')) '10.11.16' >>> See also Bug #32227.
(In reply to Philipp Hahn from comment #2) > Created attachment 7745 [details] > OpenLDAP access.log > > Currently > <http://jenkins.knut.univention.de:8080/job/UCS-4.1/job/UCS-4.1-2/job/ > AutotestJoin/lastCompletedBuild/SambaVersion=s4,Systemrolle=backup/ > testReport/junit/61_udm-users/26_password_expire_date/test/> fails since > several days. > > This is caused by something(most probably the S4C) modifying the password > expiration date in some strange way: If that modifications happens fast > enough, the test success, otherwise it fails. > I can trigger it by hand doing: > > # udm users/user create --set username=dejavu --set locked=none --set > lastname=pc3xaf9fwb --set userexpiry=2016-06-05 --position "cn=users,$(ucr > get ldap/base)" --set password=univention > # /usr/share/univention-directory-manager-tools/lock_expired_accounts > --only-last-week -n > Initializing... (Tue Jun 14 18:10:10 2016) > ... > # sleep 20 > # /usr/share/univention-directory-manager-tools/lock_expired_accounts > --only-last-week -n > Initializing... (Tue Jun 14 18:10:23 2016) > ... > uid=dejgyanmmh expired at 2016-06-07 ... skipped due to dry run (expected > modification: locked='posix') > > > The OpenLDAP-access-log shows "shadowExpire" being modified +1 several times: > $ grep shadowExpire ~/BUG/36210_udm-shadowExpire.log > reqMod: shadowExpire:+ 16958 > reqMod: shadowExpire:= 16959 > reqMod: shadowExpire:= 16960 > reqMod: shadowExpire:= 16961 > reqMod: shadowExpire:= 16962 > reqMod: shadowExpire:= 16963 > reqMod: shadowExpire:= 16964 > reqMod: shadowExpire:= 16965 > reqMod: shadowExpire:= 16966 I've created a new bug for this: Bug #41574. This needs to be fixed as erratum.
Created attachment 9080 [details] 36210-udm-user-expiry-421.patch The attached patch fixes the timezone conversion problem for `userexpiry` (shadowExpire, sambaKickoffTime) and a minor problem with `passwordexpiry`. The special cases are now again included in the 25_script_lock* tests. They are passing on the timezones CEST (Germany/Berlin) and AST (America/Barbados).
Code rebased on 4.2-2 in branch loyen/36210-udm-excact-user-expiry-422.
Created attachment 9406 [details] test_userexpiry_in_other_timezone.sh Test-Script showing the problem.
Created attachment 9409 [details] test_userexpiry_in_other_timezone.sh Test only works with S4-Connector, now checks that it is installed.
See Bug #41574 for more information and patches
I rebased the branch to UCS 4.4-2: loyen/36210-udm-excact-user-expiry-422
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.