Bug 1959345 - Database 'local_id' is limiting the length of the User/Project name
Summary: Database 'local_id' is limiting the length of the User/Project name
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ga
: 17.0
Assignee: Grzegorz Grasza
QA Contact: Jeremy Agee
URL:
Whiteboard:
: 1998531 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-11 10:40 UTC by Andre
Modified: 2024-12-20 20:03 UTC (History)
8 users (show)

Fixed In Version: openstack-keystone-19.0.1-0.20211027191538.ddd9730
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-21 12:14:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1929066 0 None None None 2021-05-20 12:21:42 UTC
OpenStack gerrit 792587 0 None MERGED Update local_id limit to 255 characters 2021-09-14 11:45:33 UTC
OpenStack gerrit 806381 0 None NEW Update local_id limit to 255 characters 2021-09-14 11:45:28 UTC
Red Hat Issue Tracker OSP-3754 0 None None None 2022-04-07 17:32:45 UTC
Red Hat Product Errata RHEA-2022:6543 0 None None None 2022-09-21 12:15:25 UTC

Description Andre 2021-05-11 10:40:13 UTC
Description of problem:
Customer can't query some resources due to an issue between LDAP field and OpenStack:
The investigation started with this error from customer (I'll post the log with the correct values on the next comment as private):
~~~
String length exceeded. The length of string 'AA-BBBBBB-CCCC-DDDDDDDDDDD-EEEEEEE-FFFFFFFFFFFFF-GGGGGGGGGGGGG-HH' exceeds the limit of column local_id(CHAR(64)). (HTTP 400) (Request-ID: req-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
~~~

From an upstream bug[1] we had the following solution:
~~~
The workaround for this issue is to not use objectGUID as the user or group ID. However, that workaround might not be applicable in all situations. For example, the default value for user_id_attribute is 'cn', but if that value spans more than 64 characters, keystone can't work with it.
~~~

But for security reasons, customer can't change the field mapped.

So the other solution for this could be changing the value of max_param_size on keystone configuration[2]:
~~~
[DEFAULT]
[...]
# Limit the sizes of user & project ID/names. (integer value)
#max_param_size = 64
~~~

But this parameter is not reflecting on the actual limit size, I actually couldn't find where this is being used on the code;
Using the default value (64) I was able to create a user with more than 64 characters (I don't know how to change the ID, but since the parameter is supposed to limit both ID and name, testing it just with the name should work):
~~~
[root@controller-0 ~]# grep max_param_size /var/lib/config-data/keystone/etc/keystone/keystone.conf 
#max_param_size = 64
# Similar to `[DEFAULT] max_param_size`, but provides an exception for token
[root@controller-0 ~]# 

=====

(overcloud) [stack@undercloud-0 ~]$ openstack user create aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg # 64 characters
No password was supplied, authentication will fail when a user does not have a password.
+---------------------+------------------------------------------------------------------+
| Field               | Value                                                            |
+---------------------+------------------------------------------------------------------+
| domain_id           | default                                                          |
| enabled             | True                                                             |
| id                  | 599b18e330bb4b1886f996cc35b169c1                                 |
| name                | aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg |
| options             | {}                                                               |
| password_expires_at | None                                                             |
+---------------------+------------------------------------------------------------------+
(overcloud) [stack@undercloud-0 ~]$ 

(overcloud) [stack@undercloud-0 ~]$ openstack user create aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggghh # 66 characters
No password was supplied, authentication will fail when a user does not have a password.
+---------------------+--------------------------------------------------------------------+
| Field               | Value                                                              |
+---------------------+--------------------------------------------------------------------+
| domain_id           | default                                                            |
| enabled             | True                                                               |
| id                  | c22eab2648624fad82d6fd925962445d                                   |
| name                | aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggghh |
| options             | {}                                                                 |
| password_expires_at | None                                                               |
+---------------------+--------------------------------------------------------------------+


(overcloud) [stack@undercloud-0 ~]$ openstack user list
+----------------------------------+--------------------------------------------------------------------+
| ID                               | Name                                                               |
+----------------------------------+--------------------------------------------------------------------+
| 0a4036ae92084c098575141da51f9d98 | neutron                                                            |
| 44864fdba2f2413fb05a427da7da8535 | gnocchi                                                            |
| 599b18e330bb4b1886f996cc35b169c1 | aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggg   |
| 5df8a2b9040648d1be5df64c6c3a8926 | nova                                                               |
| 6b630377adea4941bd61a16f72fcb25f | ceilometer                                                         |
| 7873d0a3da6b464688112a34874e6125 | swift                                                              |
| 78c417ac4eaf4ce88f4ec47507477307 | panko                                                              |
| 9858f21827c3415aa8f654ae8dd574a4 | placement                                                          |
| a179350bbbcd4581b48a6198be00d007 | admin                                                              |
| a6f6f94a922f4888b50a8fd1e2b5baf1 | heat                                                               |
| aa117d550d14449bbe8366401998ccde | aodh                                                               |
| ae5b2042d8b245fdbf4f679cd0a73429 | cinder                                                             |
| b838d04566974fa584040a08aa066d3c | heat_stack_domain_admin                                            |
| c22eab2648624fad82d6fd925962445d | aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggghh |
| e477e3e4aa8a4a9899c9083b23aee855 | glance                                                             |
| f003b1c512fa45b388811a0970b6f276 | heat-cfn                                                           |
+----------------------------------+--------------------------------------------------------------------+
(overcloud) [stack@undercloud-0 ~]$ 
~~~

Looking at the code (For the customer issue), I believe this is being hardcoded[3]:
~~~
class IDMapping(sql.ModelBase, sql.ModelDictMixin):
    __tablename__ = 'id_mapping'
    [...]
    local_id = sql.Column(sql.String(64), nullable=False)
~~~

My question is, do we have any solution for that? Could we increase this value safely?
Also, why the user name and the id are being treated differently? Since I can create a user exceeding the name length limit, but not the id.


[1] https://bugs.launchpad.net/keystone/+bug/1889936/comments/1
[2] https://docs.openstack.org/keystone/queens/configuration/samples/keystone-conf.html
[3] https://github.com/openstack/keystone/blob/stable/queens/keystone/identity/mapping_backends/sql.py#L24


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 9 Grzegorz Grasza 2021-06-09 06:45:49 UTC
Looks like the case can be closed. The customer found a way to apply group_filter which filter the long names. We are keeping this bug open to track the change in the database schema.

Comment 11 Grzegorz Grasza 2021-08-30 14:50:49 UTC
*** Bug 1998531 has been marked as a duplicate of this bug. ***

Comment 15 Yaniv Kaul 2022-06-02 09:06:39 UTC
(In reply to Grzegorz Grasza from comment #9)
> Looks like the case can be closed. The customer found a way to apply
> group_filter which filter the long names. We are keeping this bug open to
> track the change in the database schema.

1. Any updates?
2. Is it still urgent?

Comment 16 Grzegorz Grasza 2022-06-14 06:43:35 UTC
The patch was merged downstream, I'm changing the state to modified.

Comment 25 errata-xmlrpc 2022-09-21 12:14:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:6543


Note You need to log in before you can comment on or make changes to this bug.