Name validations for compute resources

Bug #1206396 reported by Rohan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Undecided
Aswad Rangnekar
OpenStack Compute (nova)
Undecided
Unassigned
OpenStack Identity (keystone)
Wishlist
Rohan
oslo-incubator
Undecided
Aswad Rangnekar

Bug Description

There is no consistent validation for the 'name' parameter across compute resources. The following characters need to be validated in the input:

1. One more whitespaces (like ' ' or ' ') -
2. Leading or trailing whitespaces (like ' test123 ')

Currently flavor name, volume name, role name, group name, security group name and keypair name accept input in each of the two cases (no validation).

Adding the two cases above to name parameter validation would be useful.
It makes sense to move this validation code to a common utility that can be used across all Create resource methods.
Although the 'name' is not as significant the resource's ID, it does act as a label for the resource and should be validated properly.

For example, from the dasbhboard, a role with a blank name, i.e single whitespace string like ' ' can be created. This get's stored in the keystone db as NULL and appears in the dashboard roles drop down during Create User as None. This behavior should be fixed.

Refer: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3086 _validate_new_keypair() can be moved to a common utility to provide 'name' field validations.

Rohan (kanaderohan)
Changed in nova:
assignee: nobody → Rohan (kanaderohan)
Tiantian Gao (gtt116)
Changed in nova:
status: New → Confirmed
tags: added: api
Revision history for this message
Sumanth Nagadavalli (sumanth-nagadavalli) wrote :

I think we should look at its bigger picture. I want to ask the following questions,

1. Should we also look into the extra spaces in other resources?

2. What are the other restrictions we should put on a resource's name, apart from extra spaces?

3. Should we define a guideline for names, ids etc while creating resources?

Revision history for this message
Rohan (kanaderohan) wrote :

I agree that there is no guideline stating acceptable names/ids while creating/updating resources.

This guideline should be implemented in a separate blueprint itself.

Rohit Karajgi (rohitk)
summary: - Leading and trailing whitespaces in Flavor name
+ Name validations for compute resources
description: updated
Revision history for this message
Rohit Karajgi (rohitk) wrote :

Added Keystone as an affected project since Blank role names (like (' ')are accepted and stored in database as NULL,
and show on the dashboard drop down list as "None". Such role names should be validated.

description: updated
Rohan (kanaderohan)
Changed in keystone:
assignee: nobody → Rohan (kanaderohan)
Rohit Karajgi (rohitk)
affects: nova → cinder
Changed in nova:
status: New → Confirmed
Rohan (kanaderohan)
Changed in nova:
assignee: nobody → Rohan (kanaderohan)
Revision history for this message
Xiaoxi Chen (xiaoxi-chen) wrote :

Could we move this validation to OSLO ?

Rohan (kanaderohan)
Changed in oslo:
assignee: nobody → Rohan (kanaderohan)
Revision history for this message
Dolph Mathews (dolph) wrote :

UTR against keystone directly (sounds like a bug between horizon and keystoneclient?). Attempting to create a role with a single space as the name behaves as expected (the name is stored correctly in the sql driver, not as a null value).

POST http://localhost:35357/v3/roles
{"role": {"name": " "}}

{
  "role": {
    "id": "9cf9fc40486947539a10400e638b9e65",
    "links": {
      "self": "http://localhost:5000/v3/roles/9cf9fc40486947539a10400e638b9e65"
    },
    "name": " "
  }
}

GET http://localhost:35357/v3/roles

{
  "roles": [
    {
      "id": "9cf9fc40486947539a10400e638b9e65",
      "links": {
        "self": "http://localhost:5000/v3/roles/9cf9fc40486947539a10400e638b9e65"
      },
      "name": " "
    }
  ],
  "links": {
    "self": "http://localhost:5000/v3/roles",
    "next": null,
    "previous": null
  }
}

Changed in keystone:
assignee: Rohan (kanaderohan) → nobody
status: New → Invalid
Revision history for this message
Rohit Karajgi (rohitk) wrote :

Hi Dolph,

Should whitespace only role names be allowed? Please see attached horizon screenshot where this could be confusing to a user.

Changed in keystone:
status: Invalid → New
Revision history for this message
Rohit Karajgi (rohitk) wrote :

I've compiled a matrix showing the impact across various Create API for three categories of invalid input here:
https://docs.google.com/file/d/0BwufSlaYow2GaUx5U0lFQVZ0czg/edit?usp=sharing.

In my opinion, for the "name" field, a common validation logic should be applied to all the above resources.
So all the cases where the Invalid input is Accepted, should be correctly validated and disallowed.

Revision history for this message
Rohit Karajgi (rohitk) wrote :

Ideally, a resource's name should be restricted by the following validations:
* Length is >0 and <=255
* Characters fall within the set [a-zA-Z0-9_.- ]
* No leading and/or trailing white spaces

Revision history for this message
Dolph Mathews (dolph) wrote :

> Should whitespace only role names be allowed?

> Characters fall within the set [a-zA-Z0-9_.- ]

I'm opposed to mandating that services arbitrarily constrain user-facing labels to a particular character set, etc, beyond what is absolutely necessary (e.g. maximum length as dictated by the persistence mechanism in use by a particular deployment).

Revision history for this message
Rohit Karajgi (rohitk) wrote :
Revision history for this message
Rohit Karajgi (rohitk) wrote :

https://docs.google.com/file/d/0BwufSlaYow2GUUZJVlJYVGM2VVU/edit?usp=sharing is updated with some more clarity.

> I'm opposed to mandating that services arbitrarily constrain user-facing labels to a particular character set, etc, beyond what is absolutely necessary

I agree that user facing labels need not be overly validated, however what I am concerned about is the standardization of validation across API.
For example, in Keystone, referring to the above spreadsheet, create tenant and create user reject input that is just one or more white spaces, where we can create a group or a role with such input.
Similarly, leading or trailing white spaces are stripped from the input in the case of create user and tenant, but not so for group and role.
Such deviations could be rectified with some minor fixes. Thoughts?

Revision history for this message
Ben Nemec (bnemec) wrote :

IMHO this is not a bug in Oslo, but a feature request. Please open a blueprint against Oslo to track this work (I do agree that common code to do validation is a good idea) Obviously there is some significant discussion needed first, so I would also suggest sending something to openstack-dev on this topic.

Thanks.

Changed in oslo:
status: New → Invalid
Revision history for this message
Rohit Karajgi (rohitk) wrote :

Most of the thoughts seem to be in the direction of having the validations done by Oslo,
I have created a blueprint to track this feature: https://blueprints.launchpad.net/oslo/+spec/api-validation-utility.
Implementation is already in good progress and there should be a patch for Oslo soon.

Dolph Mathews (dolph)
Changed in keystone:
importance: Undecided → Wishlist
Changed in cinder:
assignee: Rohan (kanaderohan) → Aswad Rangnekar (aswad-r)
Changed in keystone:
assignee: nobody → Aswad Rangnekar (aswad-r)
Changed in nova:
assignee: Rohan (kanaderohan) → Aswad Rangnekar (aswad-r)
Changed in oslo:
assignee: Rohan (kanaderohan) → Aswad Rangnekar (aswad-r)
Revision history for this message
Dolph Mathews (dolph) wrote :

Unassigning due to inactivity.

Changed in keystone:
assignee: Aswad Rangnekar (aswad-r) → nobody
Rohan (kanaderohan)
Changed in keystone:
assignee: nobody → Rohan (kanaderohan)
Revision history for this message
Sean Dague (sdague) wrote :

There are ongoing discussions on the mailing list right now about this. I think it's not a bug per say (actually current Nova behavior is what's asked for).

Changed in nova:
assignee: Aswad Rangnekar (aswad-r) → nobody
status: Confirmed → Opinion
Changed in keystone:
status: New → Confirmed
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote : Bug Cleanup

Closing stale bug. If this is still an issue please reopen.

Changed in cinder:
status: Confirmed → Invalid
Revision history for this message
Steve Martinelli (stevemar) wrote :

marking keystone as invalid since we have a duplicate bug here: 1519580 and we now use JSON schema validation for our v3 calls

Changed in keystone:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments