Bug 1959345

Summary: Database 'local_id' is limiting the length of the User/Project name
Product: Red Hat OpenStack Reporter: Andre <afariasa>
Component: openstack-keystoneAssignee: Grzegorz Grasza <ggrasza>
Status: CLOSED ERRATA QA Contact: Jeremy Agee <jagee>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 13.0 (Queens)CC: alee, dwilde, elicohen, ggrasza, jfindysz, jmelvin, ldenny, oblaut
Target Milestone: gaKeywords: Triaged
Target Release: 17.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-keystone-19.0.1-0.20211027191538.ddd9730 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-09-21 12:14:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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