MySQL rounds timestamps
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Lance Bragstad |
Bug Description
It was known that MySQL would *truncate* datetimes before inserting them. In the process of debugging issues with making fernet the default, I found that MySQL will actually *round* in some cases.
To create I did the following:
1.) Stand up a fresh devstack
2.) Switch `CONF [token] provider = fernet` in /etc/keystone/
3.) Litter keystone with timing debug statements - http://
4.) Run ./run_tempest.sh tempest.
The tests creates a new user, changes their password, authenticates for a fresh token, and expects the new token to be valid. When the test fails, keystone returns a 404 saying the token isn't found even though the token was created more than one second after the password was changed...
Here is the output from tempest: http://
Here is the output from keystone with additional logging: http://
We can see that the revocation event is being persisted at 2016-09-
What I think is happening here is that when revocation events are created during the last half of a second - the timestamps are getting rounded to the next second. This naturally works against the Fernet implementation because the Fernet implementation will *always* truncate it's issued_at time [0].
In the worst case, if a revocation event is created at 2016-09-
I did this on a devstack install on Ubuntu 16.04 and MySQL Server version: 5.7.13-
tags: | added: fenet |
tags: |
added: fernet revoke removed: fenet |
description: | updated |
description: | updated |
Changed in keystone: | |
importance: | Undecided → Critical |
importance: | Critical → High |
description: | updated |
Changed in keystone: | |
milestone: | none → newton-rc1 |
tags: | added: rc-potential |
Fix proposed to branch: master /review. openstack. org/368244
Review: https:/