yahoo-eng-team team mailing list archive

[Slawek Kaplonski <2065743@xxxxxxxxxxxxxxxxxx>]

After thinking about this a bit more I think that 404 and 403 are not
handled in the same way on the OSC side to not give user who shouldn't
have access the target project any information about if it exists or
not. So I think that there we also can't really do anything more. I
think that update to our api-ref:
https://review.opendev.org/c/openstack/neutron-lib/+/920870 have to be
enough to address this bug.

** Changed in: neutron
       Status: Triaged => In Progress

** Changed in: python-openstackclient
       Status: Confirmed => Opinion

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

Title:
  CLI arguments for rbac create are misleading and possibly incorrect

Status in neutron:
  In Progress
Status in python-openstackclient:
  Opinion

Bug description:
  On a yoga install of openstack, I can run the following command as
  user with member role in projectA which is in domain DOM:

    openstack network rbac create --target-project projectB --target-
  project-domain DOM --action access_as_shared --type security_group my-
  security-group

  The user doesn't have any role for project projectB but can
  successfully create an rbac for it. However, when I see the fields of
  the rbac, I see:

    | target_project_id | projectB                  |

  The RBAC then fails to work as expected, because this is not an ID.
  If, instead, I create the rbac using an explicit ID of the project,
  then the RBAC behaves as expected.

  From what I understand, the user cannot see "projectB" so there is no
  way for the CLI to lookup its ID. However, I would expect the CLI in
  this case to reply:

    "Cannot create rbac from name without permissions to list projects.
  Please use an ID instead"

  I note that if use a user who is allowed to list projects, then when I
  create an rbac, the ID of the project appears in the fields of the
  rbac.

  This bug is somewhat related to
  https://bugs.launchpad.net/neutron/+bug/1649909. The difference is
  that here we are not trying to create a "domain-scoped" rbac, but the
  confusion surrounding the `--target-project-domain` argument is still
  a problem.

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