Updating a project's domain_id can create an illegal project hierarchy

Bug #1502157 reported by Henry Nash
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
Henrique Truta

Bug Description

We introduced hierarchical projects in Kilo. The design (both then and now) was that a project hierarchy existed in a single domain (i.e. all the projects in the hierarchy were owned by the same domain).

We also still support (although disabled by default) the ability to change the domain_id of a user, group or project. This is being marked as deprecated in Mitaka.

The problem arrises if a cloud deployer changes the config to allow mutable domain_ids, creates a hierarchy of projects and then changes the domain of a project in the middle of the hierarchy. The hierarchy is now not all owned by the same domain. This ability to change a project that has children or is not a top level project is being removed in Mitaka (we should never have allowed it) - but the fact remains that (however unlikely) someone might have done this in Kilo or Liberty.

The question is what to do about it? About the least bad solution I can think of would be to do both:

1) Backport the restriction to stop projects having their domain_id change unless they are a top level project with no children to Liberty (and maybe Kilo). We can't back port the deprecation, or course.

2) Add migration code in Mitaka that spotted a "split hierarchy" and really split the hierarchy (i.e. the two part of the project tree would hang off their respective domains). To really do that right, we'd have to duplicate any inherited role assignments.

Revision history for this message
Henry Nash (henry-nash) wrote :

Another option, instead of 2) above is that we would spot the error on migrate and fail the migration, and ask them to run keystone-manage with a special command that could give them an interactive option in terms of what to do about assignments and splitting etc. I kind of think this is not worth it, since I'm not sure what really options they have except a straightly split.

Changed in keystone:
status: New → Confirmed
Revision history for this message
Alexander Makarov (amakarov) wrote :

I can suggest the following behavior:

1. include materialized path (https://review.openstack.org/#/c/198418/) in projects
2. hook domain_id change so that remaining hierarchy is rearranged excluding "lost" project from ancestry chains (pedigrees) it was included into.

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

Ownership, especially in hierarchies, must be immutable. The fallout of bugs otherwise is simply not worth it while the feature is so immature.

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

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

commit 27c4cbc9f7565ee978525de0053a1ae5f15de633
Author: henriquetruta <email address hidden>
Date: Wed Jul 29 17:49:32 2015 -0300

    Restricting domain_id update

    Restricts the update of a domain_id for a project, (even with the
    'domain_id_immutable' property set to False), allowing it only for
    root projects that have no children of its own. The update of the
    domain_id of a project that has the is_domain field set True is not
    allowed either. The update of this property may cause projects hierarchy
    inconsistency and security issues.
    This patch also sets the 'domain_id_immutable' as deprecated and emits
    a WARN in case it is set False, when updating the domain_id of
    users, groups or projects.

    Closes-bug: 1479452
    Related-bug: 1502157

    Change-Id: Ib53f2173d4e4694d7ed2ecd330878664f8199371

Changed in keystone:
status: Confirmed → Fix Committed
importance: Undecided → Medium
milestone: none → mitaka-3
assignee: nobody → Henrique Truta (henriquetruta)
Changed in keystone:
status: Fix Committed → Fix Released
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.