Bug 36210 - Handling of userexpiry is unexact
Handling of userexpiry is unexact
Status: REOPENED
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
UCS 5.0
Other Linux
: P5 normal (vote)
: UCS 5.x
Assigned To: UMC maintainers
:
Depends on:
Blocks: 35900 41574
  Show dependency treegraph
 
Reported: 2014-10-16 12:07 CEST by Sönke Schwardt-Krummrich
Modified: 2020-07-13 11:14 CEST (History)
6 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?: 3: Will affect average number of 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.103
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:
oyen: Patch_Available+


Attachments
OpenLDAP access.log (16.14 KB, text/plain)
2016-06-14 16:31 CEST, Philipp Hahn
Details
36210-udm-user-expiry-421.patch (9.41 KB, patch)
2017-07-31 17:27 CEST, Lukas Oyen
Details | Diff
test_userexpiry_in_other_timezone.sh (1.30 KB, application/x-shellscript)
2018-02-21 16:39 CET, Arvid Requate
Details
test_userexpiry_in_other_timezone.sh (1.40 KB, application/x-shellscript)
2018-02-21 16:53 CET, Arvid Requate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2014-10-16 12:07:39 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.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2014-10-21 09:11:29 CEST
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.
Comment 2 Philipp Hahn univentionstaff 2016-06-14 16:31:03 CEST
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
Comment 3 Philipp Hahn univentionstaff 2016-06-14 16:43:08 CEST
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
Comment 4 Stefan Gohmann univentionstaff 2016-06-14 17:01:56 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.
Comment 5 Stefan Gohmann univentionstaff 2016-06-15 06:26:04 CEST
(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.
Comment 6 Lukas Oyen univentionstaff 2017-07-31 17:27:48 CEST
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).
Comment 7 Lukas Oyen univentionstaff 2017-09-11 15:58:33 CEST
Code rebased on 4.2-2 in branch loyen/36210-udm-excact-user-expiry-422.
Comment 8 Arvid Requate univentionstaff 2018-02-21 16:39:21 CET
Created attachment 9406 [details]
test_userexpiry_in_other_timezone.sh

Test-Script showing the problem.
Comment 9 Arvid Requate univentionstaff 2018-02-21 16:53:13 CET
Created attachment 9409 [details]
test_userexpiry_in_other_timezone.sh

Test only works with S4-Connector, now checks that it is installed.
Comment 10 Felix Botner univentionstaff 2018-02-22 14:09:25 CET
See Bug #41574 for more information and patches
Comment 11 Florian Best univentionstaff 2019-10-30 14:47:06 CET
I rebased the branch to UCS 4.4-2: loyen/36210-udm-excact-user-expiry-422
Comment 12 Ingo Steuwer univentionstaff 2020-07-03 20:55:33 CEST
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.