For reference, here is our full glance policy.json
{ "context_is_admin": "role:admin", "default": "role:admin", "add_image": "", "delete_image": "", "get_image": "", "get_images": "", "modify_image": "", "publicize_image": "role:admin", "communitize_image": "", "copy_from": "", "download_image": "", "upload_image": "", "delete_image_location": "", "get_image_location": "", "set_image_location": "", "add_member": "", "delete_member": "", "get_member": "", "get_members": "", "modify_member": "", "manage_image_cache": "role:admin", "get_task": "", "get_tasks": "", "add_task": "", "modify_task": "", "tasks_api_access": "role:admin", "deactivate": "", "reactivate": "", "get_metadef_namespace": "", "get_metadef_namespaces":"", "modify_metadef_namespace":"", "add_metadef_namespace":"", "get_metadef_object":"", "get_metadef_objects":"", "modify_metadef_object":"", "add_metadef_object":"", "list_metadef_resource_types":"", "get_metadef_resource_type":"", "add_metadef_resource_type_association":"", "get_metadef_property":"", "get_metadef_properties":"", "modify_metadef_property":"", "add_metadef_property":"", "get_metadef_tag":"", "get_metadef_tags":"", "modify_metadef_tag":"", "add_metadef_tag":"", "add_metadef_tags":"" } Mike Moore, M.S.S.E. Systems Engineer, Goddard Private Cloud michael.d.mo...@nasa.gov Hydrogen fusion brightens my day. On 10/19/18, 12:39 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.mo...@nasa.gov> wrote: Our NDC domain is LDAP backed. Default is not. Our keystone policy.json file is empty {} Mike Moore, M.S.S.E. Systems Engineer, Goddard Private Cloud michael.d.mo...@nasa.gov Hydrogen fusion brightens my day. On 10/18/18, 7:24 PM, "Chris Apsey" <bitskr...@bitskrieg.net> wrote: We are using multiple keystone domains - still can't reproduce this. Do you happen to have a customized keystone policy.json? Worst case, I would launch a devstack of your targeted release. If you can't reproduce the issue there, you would at least know its caused by a nonstandard config rather than a bug (or at least not a bug that's present when using a default config) On October 18, 2018 18:50:12 iain MacDonnell <iain.macdonn...@oracle.com> wrote: > That all looks fine. > > I believe that the "default" policy applies in place of any that's not > explicitly specified - i.e. "if there's no matching policy below, you > need to have the admin role to be able to do it". I do have that line in > my policy.json, and I cannot reproduce your problem (see below). > > I'm not using domains (other than "default"). I wonder if that's a factor... > > ~iain > > > $ openstack user create --password foo user1 > +---------------------+----------------------------------+ > | Field | Value | > +---------------------+----------------------------------+ > | domain_id | default | > | enabled | True | > | id | d18c0031ec56430499a2d690cb1f125c | > | name | user1 | > | options | {} | > | password_expires_at | None | > +---------------------+----------------------------------+ > $ openstack user create --password foo user2 > +---------------------+----------------------------------+ > | Field | Value | > +---------------------+----------------------------------+ > | domain_id | default | > | enabled | True | > | id | be9f1061a5104abd834eabe98dff055d | > | name | user2 | > | options | {} | > | password_expires_at | None | > +---------------------+----------------------------------+ > $ openstack project create project1 > +-------------+----------------------------------+ > | Field | Value | > +-------------+----------------------------------+ > | description | | > | domain_id | default | > | enabled | True | > | id | 826876d6d3724018bae6253c7f540cb3 | > | is_domain | False | > | name | project1 | > | parent_id | default | > | tags | [] | > +-------------+----------------------------------+ > $ openstack project create project2 > +-------------+----------------------------------+ > | Field | Value | > +-------------+----------------------------------+ > | description | | > | domain_id | default | > | enabled | True | > | id | b446b93ac6e24d538c1943acbdd13cb2 | > | is_domain | False | > | name | project2 | > | parent_id | default | > | tags | [] | > +-------------+----------------------------------+ > $ openstack role add --user user1 --project project1 _member_ > $ openstack role add --user user2 --project project2 _member_ > $ export OS_PASSWORD=foo > $ export OS_USERNAME=user1 > $ export OS_PROJECT_NAME=project1 > $ openstack image list > +--------------------------------------+--------+--------+ > | ID | Name | Status | > +--------------------------------------+--------+--------+ > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active | > +--------------------------------------+--------+--------+ > $ openstack image create --private image1 > +------------------+------------------------------------------------------------------------------+ > | Field | Value > | > +------------------+------------------------------------------------------------------------------+ > | checksum | None > | > | container_format | bare > | > | created_at | 2018-10-18T22:17:41Z > | > | disk_format | raw > | > | file | > /v2/images/6a0c1928-b79c-4dbf-a9c9-305b599056e4/file > | > | id | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 > | > | min_disk | 0 > | > | min_ram | 0 > | > | name | image1 > | > | owner | 826876d6d3724018bae6253c7f540cb3 > | > | properties | locations='[]', os_hash_algo='None', > os_hash_value='None', os_hidden='False' | > | protected | False > | > | schema | /v2/schemas/image > | > | size | None > | > | status | queued > | > | tags | > | > | updated_at | 2018-10-18T22:17:41Z > | > | virtual_size | None > | > | visibility | private > | > +------------------+------------------------------------------------------------------------------+ > $ openstack image list > +--------------------------------------+--------+--------+ > | ID | Name | Status | > +--------------------------------------+--------+--------+ > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active | > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued | > +--------------------------------------+--------+--------+ > $ export OS_USERNAME=user2 > $ export OS_PROJECT_NAME=project2 > $ openstack image list > +--------------------------------------+--------+--------+ > | ID | Name | Status | > +--------------------------------------+--------+--------+ > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active | > +--------------------------------------+--------+--------+ > $ export OS_USERNAME=admin > $ export OS_PROJECT_NAME=admin > $ export OS_PASSWORD=xxx > $ openstack image set --public 6a0c1928-b79c-4dbf-a9c9-305b599056e4 > $ export OS_USERNAME=user2 > $ export OS_PROJECT_NAME=project2 > $ export OS_PASSWORD=foo > $ openstack image list > +--------------------------------------+--------+--------+ > | ID | Name | Status | > +--------------------------------------+--------+--------+ > | ad497523-b497-4500-8e6c-b5fb12a30cee | cirros | active | > | 6a0c1928-b79c-4dbf-a9c9-305b599056e4 | image1 | queued | > +--------------------------------------+--------+--------+ > $ > > > On 10/18/2018 03:32 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS > INTEGRA, INC.] wrote: >> openstack user create --domain default --password xxxxxxxx --project-domain >> ndc --project test mike >> >> >> openstack role add --user mike --user-domain default --project test user >> >> my admin account is in the NDC domain with a different username. >> >> >> >> /etc/glance/policy.json >> { >> >> "context_is_admin": "role:admin", >> "default": "role:admin", >> >> <snip> >> >> >> I'm not terribly familiar with the policies but I feel like that default >> line is making everyone an admin by default? >> >> >> Mike Moore, M.S.S.E. >> >> Systems Engineer, Goddard Private Cloud >> michael.d.mo...@nasa.gov >> >> Hydrogen fusion brightens my day. >> >> >> On 10/18/18, 6:25 PM, "iain MacDonnell" <iain.macdonn...@oracle.com> wrote: >> >> >> I suspect that your non-admin user is not really non-admin. How did you >> create it? >> >> What you have for "context_is_admin" in glance's policy.json ? >> >> ~iain >> >> >> On 10/18/2018 03:11 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS >> INTEGRA, INC.] wrote: >>> I have replicated this unexpected behavior in a Pike test environment, in >>> addition to our Queens environment. >>> >>> >>> >>> Mike Moore, M.S.S.E. >>> >>> Systems Engineer, Goddard Private Cloud >>> michael.d.mo...@nasa.gov >>> >>> Hydrogen fusion brightens my day. >>> >>> >>> On 10/18/18, 2:30 PM, "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, >>> INC.]" <michael.d.mo...@nasa.gov> wrote: >>> >>> Yes. I verified it by creating a non-admin user in a different tenant. I >>> created a new image, set to private with the project defined as our admin >>> tenant. >>> >>> In the database I can see that the image is 'private' and the owner is the >>> ID of the admin tenant. >>> >>> Mike Moore, M.S.S.E. >>> >>> Systems Engineer, Goddard Private Cloud >>> michael.d.mo...@nasa.gov >>> >>> Hydrogen fusion brightens my day. >>> >>> >>> On 10/18/18, 1:07 AM, "iain MacDonnell" <iain.macdonn...@oracle.com> wrote: >>> >>> >>> >>> On 10/17/2018 12:29 PM, Moore, Michael Dane (GSFC-720.0)[BUSINESS >>> INTEGRA, INC.] wrote: >>> > I’m seeing unexpected behavior in our Queens environment related to >>> > Glance image visibility. Specifically users who, based on my >>> > understanding of the visibility and ownership fields, should NOT be able >>> > to see or view the image. >>> > >>> > If I create a new image with openstack image create and specify –project >>> > <tenant> and –private a non-admin user in a different tenant can see and >>> > boot that image. >>> > >>> > That seems to be the opposite of what should happen. Any ideas? >>> >>> Yep, something's not right there. >>> >>> Are you sure that the user that can see the image doesn't have the admin >>> role (for the project in its keystone token) ? >>> >>> Did you verify that the image's owner is what you intended, and that the >>> visibility really is "private" ? >>> >>> ~iain >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e= >>> >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Doperators&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=RxYkIjeLZPK2frXV_wEUCq8d3wvUIvDPimUcunMwbMs&m=B-M8uELxrmQ5uIYT792YA5rpb5NLAecRQPH_ITY1R5k&s=1KSr8HB8BJJB4-nGHyuZDcQUdssno-bBdbNqswMm6oE&e= > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators