[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2023-03-24 Thread Adam Young 
If it is not fixed in Nova it is not fixed in Keystone, as the solution
has to start there.

** Changed in: keystone
   Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Confirmed
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Confirmed
Status in puppet-keystone:
  Invalid

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

  
  Note:  See changes ongoing under 
https://bugs.launchpad.net/neutron/+bug/1602081  which is required before 
policy changes can enforce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2022-10-20 Thread Rodolfo Alonso 
** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Committed
Status in puppet-keystone:
  Invalid

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

  
  Note:  See changes ongoing under 
https://bugs.launchpad.net/neutron/+bug/1602081  which is required before 
policy changes can enforce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2021-05-04 Thread Adam Young 
** Changed in: neutron
   Status: Triaged => Fix Committed

** Changed in: nova
   Status: In Progress => Fix Committed

** Changed in: puppet-keystone
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Committed
Status in OpenStack Compute (nova):
  Fix Committed
Status in puppet-keystone:
  Invalid

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

  
  Note:  See changes ongoing under 
https://bugs.launchpad.net/neutron/+bug/1602081  which is required before 
policy changes can enforce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2019-09-30 Thread Lance Bragstad 
** Changed in: keystone
Milestone: None => train-rc1

** Changed in: keystone
   Status: In Progress => Fix Committed

** Changed in: keystone
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Triaged
Status in OpenStack Compute (nova):
  In Progress
Status in puppet-keystone:
  New

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

  
  Note:  See changes ongoing under 
https://bugs.launchpad.net/neutron/+bug/1602081  which is required before 
policy changes can enforce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2016-10-10 Thread Adam Young 
Reopening the Keystone one as the fix does not work for default policy,
which is what most people use.

** Changed in: keystone
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  In Progress
Status in neutron:
  Triaged
Status in OpenStack Compute (nova):
  In Progress
Status in puppet-keystone:
  New

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

  
  Note:  See changes ongoing under 
https://bugs.launchpad.net/neutron/+bug/1602081  which is required before 
policy changes can enforce.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2015-12-15 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/240720
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=9804081a80ef815a86407a64f967986a7bf9ba25
Submitter: Jenkins
Branch:master

commit 9804081a80ef815a86407a64f967986a7bf9ba25
Author: Adam Young 
Date:   Sun Nov 1 11:55:45 2015 -0500

Updated Cloudsample

Uses configuration options to determine if a token is for the admin
project and should be granted admin privileges.

Closes-Bug: 968696

Change-Id: Ib23452e171dc90115c77fa5a4b9dc4649054eb0e


** Changed in: keystone
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Triaged
Status in OpenStack Compute (nova):
  Confirmed
Status in puppet-keystone:
  New

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2015-11-02 Thread Richard Megginson 
** Also affects: puppet-keystone
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  In Progress
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Confirmed
Status in puppet-keystone:
  New

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: "admin"-ness not properly scoped

2015-09-03 Thread Thierry Carrez 
** Changed in: cinder
   Status: Fix Committed => Fix Released

** Changed in: cinder
Milestone: None => liberty-3

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  "admin"-ness not properly scoped

Status in Cinder:
  Fix Released
Status in Glance:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Keystone:
  Confirmed
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer "global" roles.

  Problem: Granting a user an "admin" role on ANY tenant grants them
  unlimited "admin"-ness throughout the system because there is no
  differentiation between a scoped "admin"-ness and a global
  "admin"-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: admin-ness not properly scoped

2015-07-24 Thread Adam Young 
** Also affects: glance
   Importance: Undecided
   Status: New

** Also affects: cinder
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  admin-ness not properly scoped

Status in Cinder:
  New
Status in Glance:
  New
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Keystone:
  Confirmed
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer global roles.

  Problem: Granting a user an admin role on ANY tenant grants them
  unlimited admin-ness throughout the system because there is no
  differentiation between a scoped admin-ness and a global
  admin-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: admin-ness not properly scoped

2015-07-23 Thread Thierry Carrez 
** Changed in: nova
   Status: Fix Released = Confirmed

** Changed in: nova
Milestone: 2012.2 = None

** Changed in: nova
 Assignee: Jake Dahn (jakedahn) = (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  admin-ness not properly scoped

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Keystone:
  Confirmed
Status in neutron:
  Incomplete
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer global roles.

  Problem: Granting a user an admin role on ANY tenant grants them
  unlimited admin-ness throughout the system because there is no
  differentiation between a scoped admin-ness and a global
  admin-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 968696] Re: admin-ness not properly scoped

2014-12-17 Thread Song Li 
Admin of one tenant can also create networks, routers and so on in other 
tenants, and take other actions. It might be a big risk for the security.
So I think it also affect the Neutron.

** Also affects: neutron
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/968696

Title:
  admin-ness not properly scoped

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  Fact: Keystone's rbac model grants roles to users on specific tenants,
  and post-keystone redux, there are no longer global roles.

  Problem: Granting a user an admin role on ANY tenant grants them
  unlimited admin-ness throughout the system because there is no
  differentiation between a scoped admin-ness and a global
  admin-ness.

  I don't have a specific solution to advocate, but being an admin on
  *any* tenant simply *cannot* allow you to administer all of keystone.

  Steps to reproduce (from Horizon, though you could do this with the
  CLI, too):

  1. User A (existing admin) creates Project B and User B.
  2. User A adds User B to Project B with the admin role on Project B.
  3. User B logs in and now has unlimited admin rights not only to view things 
in the dashboard, but to take actions like creating new projects and users, 
managing existing projects and users, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/968696/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp