Changing default_domain_id doesn't work

Bug #1265108 reported by Brant Knudson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
Brant Knudson

Bug Description

If you change the default_domain_id in keystone.conf, it doesn't take effect everywhere. The problem is that the value is read when modules are imported, but that happens before the call to oslo.conf.cfg.CONF().

Here's an example:

keystone.assignment.core reads CONF.identity.default_domain_id during import to build DEFAULT_DOMAIN:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/assignment/core.py?id=d38942de2f1a32d10a9dbd1d95ddda742ddbdea1#n41

Then later we get into main in keystone-all we finallly call CONF():

http://git.openstack.org/cgit/openstack/keystone/tree/bin/keystone-all?id=d38942de2f1a32d10a9dbd1d95ddda742ddbdea1#n107

so what's going to happen is that DEFAULT_DOMAIN will get a domain_id of the default domain ID and later CONF.identity.default_domain_id will get set to whatever the user had set it to.

You can see it in the debugger by setting a breakpoint after CONF() and checking the value of the config option and the DEFAULT_DOMAIN.

I'm not sure what all effects this would have.

The fix is to change the keystone server code so that it doesn't read the config value until after CONF(), which means not at import time.

----

I looked through the rest of the code and here's where a static default_domain_id is used, and my guess as to what affect it will have:

o keystone.assignment.controllers

- In class Tenant(controller.V2Controller)

  - get_projects_for_token(),
    used to filter a list of tenants,
    so will get tenants from wrong domain or no tenants/domain not found.

  - get_project_by_name(),
    passed to self.assignment_api.get_project_by_name()
    so using v2 API will get project from wrong domain or project/domain not found

- In class Role(controller.V2Controller)

  - get_role_refs()
    will get roles from wrong domain or no roles

- In class DomainV3(controller.V3Controller):

  - delete_domain()
    would allow deleting the default domain when should not

o keystone.assignment.core

- Creates a DEFAULT_DOMAIN with { 'id': CONF.identity.default_domain_id },
  so the id of the default domain will be incorrect.

  - this is used by keystone.assignment.backends.ldap,
    - get_domain(), will return domain with incorrect ID
    - list_domains(), will return domain with incorrect ID

o keystone.common.sql.migrate_repo.versions.008_create_default_domain

  - will create domain with wrong ID on upgrade
  - or fail to delete the domain on downgrade

o keystone.common.sql.migrate_repo.versions.016_normalize_domain_ids

  - will put users with wrong domain

o keystone.common.controller

- in class V2Controller
  - in _normalize_domain_id(), will fill in domain ID with wrong domain

- in class V3Controller(V2Controller)
  - _get_domain_id_for_request
    will get wrong domain ID for admin token
    will get wrong domain ID when no domain in token

o keystone.identity.controllers

- in class User(controller.V2Controller)
  - in get_user_by_name(),
    will get user from wrong domain or domain doesn't exist

o keystone.token.providers.common

- in class BaseProvider(provider.Provider)
  - in _assert_default_domain(),
    - will allow a user in non-default domain (for v2 tokens)

o keystone.token.controllers

- in class Auth(controller.V2Controller),
  - in _authenticate_local()
    will get user from wrong domain or won't find user
    (so authentication would fail)

  - in _authenticate_external()
    will get user from wrong domain

  - in _get_project_id_from_auth
    will get project from wrong domain or won't find project

Brant Knudson (blk-u)
Changed in keystone:
assignee: nobody → Brant Knudson (blk-u)
Revision history for this message
Brant Knudson (blk-u) wrote :

I tried running devstack with a non-default default_project_id. I changed lib/keystone to `iniset $KEYSTONE_CONF identity default_domain_id "blks_domain"`.

Devstack fails when tries to create tenants, and creating users also fails. Here's the output:

...
+ create_keystone_accounts
++ keystone tenant-create --name admin
++ grep ' id '
++ get_field 2
++ read data
Conflict occurred attempting to store project. (IntegrityError) (1452, 'Cannot add or update a child row: a foreign key constraint fails (`keystone`.`project`, CONSTRAINT `project_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`))') 'INSERT INTO project (id, name, domain_id, description, enabled, extra) VALUES (%s, %s, %s, %s, %s, %s)' ('96bab9b2790f412693732f9d32c32cde', 'admin', 'default', None, 1, '{}') (HTTP 409)
+ ADMIN_TENANT=
++ keystone user-create --name admin --pass ofs5dac --email <email address hidden>
++ get_field 2
++ grep ' id '
++ read data
Could not find domain, default. (HTTP 404)
...

So it can't create tenants because the ID in the database is "blks_domain"
rather than "domain" so the foreign key constraint fails.
So the migration to insert the default domain is working correctly?
It can't create the admin user because can't find the 'default' domain,
because the domain is actually "blks_domain".

description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to keystone (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/64575

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Related fix proposed to branch: master
Review: https://review.openstack.org/64586

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Related fix proposed to branch: master
Review: https://review.openstack.org/64587

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/64589

Changed in keystone:
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to keystone (master)

Related fix proposed to branch: master
Review: https://review.openstack.org/64749

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Related fix proposed to branch: master
Review: https://review.openstack.org/64759

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone (master)

Reviewed: https://review.openstack.org/64586
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6d991911b35692cc2858d31e668f40d2c99e53d8
Submitter: Jenkins
Branch: master

commit 6d991911b35692cc2858d31e668f40d2c99e53d8
Author: Brant Knudson <email address hidden>
Date: Tue Dec 31 17:05:43 2013 -0600

    Fix typo in test

    A single-char typo in test_auth caused a value that should have
    been a simple string into a tuple of strings. This made the test
    generate what's actually invalid input data since the username
    is supposed to be a simple string.

    Change-Id: I7a477bb8e5504c1c7982cf56ffe69e1c5294cadf
    Related-bug: #1265108

Dolph Mathews (dolph)
Changed in keystone:
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/64575
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6bd2394bb860491a9ba72727565b7513f2b533f4
Submitter: Jenkins
Branch: master

commit 6bd2394bb860491a9ba72727565b7513f2b533f4
Author: Brant Knudson <email address hidden>
Date: Tue Dec 31 12:54:07 2013 -0600

    Enhance tests for non-default default_domain_id

    There were no tests that show what happens when the
    default_domain_id is changed from the default. The new tests show
    that in some cases the behavior is incorrect, and in other cases
    it is correct.

    Change-Id: Ia167e153f488617f94afce7fddfc52e1e2c8e79c
    Related-Bug: #1265108

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/64587
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=feccda70db130bbcc1fb6c73582f17b3b9ef7822
Submitter: Jenkins
Branch: master

commit feccda70db130bbcc1fb6c73582f17b3b9ef7822
Author: Brant Knudson <email address hidden>
Date: Tue Dec 31 16:49:16 2013 -0600

    KVS support domain as namespace for users

    The KVS identity backend didn't support having users with the
    same name in different domains.

    Change-Id: I4f6a9010ed085aef9cba5f368e292dd28339a0fa
    Related-bug: #1265108

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/64749
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=af4c2040ec6b90f1af67c3cd93ada66ca771ce0f
Submitter: Jenkins
Branch: master

commit af4c2040ec6b90f1af67c3cd93ada66ca771ce0f
Author: Brant Knudson <email address hidden>
Date: Tue Dec 31 12:54:07 2013 -0600

    Enhance auth tests for non-default default_domain_id

    There wasn't an authentication test that showed what happens when
    the default_domain_id option is changed from the default. The new
    tests show that the behavior is incorrect.

    This test is split out because it uses a new feature of the KVS
    backend to allow adding users with the same name in different
    domains, because I don't think we'll backport that change.

    Change-Id: I890a1c798d7f4a8a345404cd7754708ab0d36651
    Related-Bug: #1265108

Changed in keystone:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/64589
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=01a6c7db3e13c21362a39bbba4543ef020906387
Submitter: Jenkins
Branch: master

commit 01a6c7db3e13c21362a39bbba4543ef020906387
Author: Brant Knudson <email address hidden>
Date: Tue Dec 31 18:30:17 2013 -0600

    Fix using non-default default_domain_id

    Changing the default_domain_id to something other than the
    default would cause several operations to not work correctly.
    This is because the value of default_domain_id was read and
    cached in several parts on import, which is before the call to
    CONF() so the cached value is the original default ('default')
    rather than the value that the operator has in the config file.

    This change removes the cached default_domain_id and instead
    reads the value when it's needed at runtime so that the
    user-configured value is used instead of the original default.

    Change-Id: I9543e2108866ed66000d75f868bbd2b1ed978b97
    Closes-Bug: #1265108

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone (master)

Reviewed: https://review.openstack.org/64759
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=d542caa47eae3d7321c8d7bcf17c26e5dce08713
Submitter: Jenkins
Branch: master

commit d542caa47eae3d7321c8d7bcf17c26e5dce08713
Author: Brant Knudson <email address hidden>
Date: Thu Jan 2 18:44:47 2014 -0600

    Don't configure on import

    The keystone.config package called config.configure() at import-
    time.

    This will make it obvious that developers can't use config
    options at import-time because packages that do that will fail on
    import.

    Change-Id: I9306f67609d782e3f49fd43908448daf1287d51c
    Related-Bug: #1265108
    Related-Bug: #1265670
    Closes-Bug: #1269785

Thierry Carrez (ttx)
Changed in keystone:
milestone: none → icehouse-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in keystone:
milestone: icehouse-3 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.