I have dug deep into the code for glance, shoving debug outputs to see what I
can find in our queens environment.
Here is my debug code (I have a lot more but this is the salient part)
LOG.debug("in enforce(), action='%s', policyvalues='%s'", action,
context.to_policy_values())
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":
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" wrote:
We are using multiple keyston
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 rath
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 b
openstack user create --domain default --password --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
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
Do you have a liberal/custom policy.json that perhaps is causing unexpected
behavior? Can't seem to reproduce this.
On October 18, 2018 18:13:22 "Moore, Michael Dane (GSFC-720.0)[BUSINESS
INTEGRA, INC.]" wrote:
I have replicated this unexpected behavior in a Pike test environment, in
addit
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)[B
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,
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
11 matches
Mail list logo