[Yahoo-eng-team] [Bug 1840647] Re: EC2 API Auth Failure

[Morgan Fainberg]

As shown here:

https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_d9c/680481/1/check/ec2
-api-functional-neutron/d9c3627/logs/etc/keystone/keystone.conf.txt.gz

You are using 'backend = oslo_cache.dict' this is no way is
representative of any configuration that should be run in production.
The dict backend will have odd edge cases and potential problems such as
mutability of the cached data. The data is housed in-memory within the
process.

Use memcached.

This is not a bug. Marking as invalid.

** Changed in: keystone
   Status: In Progress => Won't Fix

-- 
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/1840647

Title:
  EC2 API Auth Failure

Status in ec2-api:
  New
Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  When trying to validate user token through Keystone an inconsistent behavior 
is observed:
  The very first request for a given user to Keystone is successful, while the 
second and subsequent requests for the same user result in a Key Error in 
Keystone _decrypt_credential method and thus auth failure (See the attached 
traceback). The problem is observed by merely repeating the same aws-cli 
commands for the same user 2 or more times.

  After inserting some debug log messages in core.py the problem seem to
  happen in _get_credential method in keystone.credential.core:

  In first request to Keystone:
  Aug 15 20:14:13 ubuntu-vm6 devstack@keystone.service[22678]: #033[00;36mINFO 
keystone.credential.core [#033[01;36mNone 
req-14485eaa-4172-4074-ac28-aa22fea7ce32 #033[00;36mNone None#033[00;36m] 
#033[01;35m#033[00;36mcontents of credential after _get_credential are 
user_id=u'4ad247ca077743078bf6109ff5c57dc1', 
key_hash=u'716d67b1efbe8c7b46d13e6f4b5ccfbe095a3f73', 
encrypted_blob=u'gABdVZLCpdDXGjdHk3kglftCMUDnxOKWNuLR6_6ZJtVTFt7VvJ-Y7VzyfxO6JwDv88OQtSMlJzbG8hUcfFftqhH6l5jpx6eNXdhTpO6_ZF57xyey1BmFI8JYh-PWdJkYtfDsOWJzCyWACQaUXU9N2J_r83xEYx691ToCwGCrkL-NgfFX-hVy3dYl9_4-5HcCOR4RoK2VXjLdvuAjWdvWCAxiVs-kxARpT0jkoZP1dnw-zs3pgDE=',
 project_id=u'9be611818d0b4bac82ea0d468f91541b', type=u'ec2', 
id=u'11755be627c5e6f22f3a31062afbd631bbe0f3176701ea23e5284920ded89e76'#033[00m#033[00m

  In second request to Keystone:
  Aug 15 20:14:43 ubuntu-vm6 devstack@keystone.service[22678]: #033[00;36mINFO 
keystone.credential.core [#033[01;36mNone 
req-4e4cc471-f9c7-461b-9245-65f8ac8c843b #033[00;36mNone None#033[00;36m] 
#033[01;35m#033[00;36mcontents of credential after _get_credential are 
user_id=u'4ad247ca077743078bf6109ff5c57dc1', blob=u'{"access": 
"09b2bb6d93ff47098198ceaf060baa8a", "secret": 
"d25c0c2c4ef542a29f84e7924ec89773", "trust_id": null}', 
project_id=u'9be611818d0b4bac82ea0d468f91541b', type=u'ec2', 
id=u'11755be627c5e6f22f3a31062afbd631bbe0f3176701ea23e5284920ded89e76'#033[00m#033[00m

  
  => Basically _get_credential method returns normal encrypted credential 
(encrypted_blob) for the first call, and an unencrypted credential (blob) for 
the second and subsequent calls by the same credential_id after 30 seconds. 
After that, the already decrypted credential incorrectly returned by 
_get_credential is passed to _decrypt_credential which fails because there is 
no 'encrypted_blob' key in the dictionary. The stack trace for the second and 
subsequent calls led to a package named 'dogpile' and some cache-related 
methods inside it.

  The problem seem to happen due to in-place modification of the
  credential dictionary in _decrypt_credential method. During the first
  request to Keystone the normal encrypted credential dictionary is
  returned by _get_credential method and the returned result is cached.
  However, after that the credential dictionary is modified in-place by
  _decrypt_credential method. For the second and subsequent calls to the
  _get_credential for the same user it tries to return the result from
  cache. But the cached result has been modified by _decrypt_credential.
  So, the already decrypted during first request credential is returned
  and passed again to _decrypt_credential breaking it.

  The solution is to modify a copy of the credential dictionary inside
  _decrypt_credential method, not the original credential in-place (the
  same approach as in _encrypt_credential where a copy is modified).
  This way the encrypted value of the credential is cached and it does
  not gets modified afterwards. So the normal encrypted credential is
  returned from cache and passed to _decrypt_credential again and again
  even for the same user which fixes the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1840647/+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 1842930] Re: Deleted user still can delete volumes in Horizon

[Morgan Fainberg]

Added Keystonemiddleware and documentation tags. Marked as "medium"
importance as it requires documentation changes but is not
critical/RC/otherwise impacting. Clear communication of expected
behavior is important and should be found in Horizon and
Keystonemiddleware's documentation.

I am marking invalid for Keystone itself as keystone will invalidate
it's internal cache (barring cases such as in-memory [not production
quality] dict-base cache).


** Tags added: documentation

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

** Changed in: keystone
   Status: New => Confirmed

** Changed in: keystonemiddleware
   Status: New => Triaged

** Changed in: keystone
   Status: Confirmed => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystonemiddleware
   Importance: Undecided => Medium

** Changed in: keystone
   Status: Triaged => Invalid

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

Title:
  Deleted user still can delete volumes in Horizon

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (keystone):
  Invalid
Status in keystonemiddleware:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  ==Problem==
  User session in a second browser is not terminated after deleting this user 
by admin from another browser. User is still able to manage some objects 
(delete volumes, for example) in a project after being deleted by admin.

  ==Steps to reproduce==
  Install OpenStack following official docs for Stein.
  Login as admin to (Horizon) in one browser.
  Create a user with role 'member' and assign it to a project.
  Open another browser and login as created user.
  As admin user delete created user from "first" browser.
  Switch to the "second" browser and try to browse through different sections 
in the dashboard as deleted user -> instances are not shown, but deleted user 
can list images, volumes, networks. Also this deleted user can delete a volume.

  ==Expected result==
  User session in current browser is closed after user is deleted in another 
browser.
  I tried this in Newton release and it works as expected (for a short time 
before session is ended, this deleted user can't list object in 
instances,volumes).

  ==Environment==
  OpenStack Stein
  rpm -qa | grep -i stein
  centos-release-openstack-stein-1-1.el7.centos.noarch

  cat /etc/redhat-release
  CentOS Linux release 7.6.1810 (Core)

   rpm -qa | grep -i horizon
  python2-django-horizon-15.1.0-1.el7.noarch

  rpm -qa | grep -i dashboard
  openstack-dashboard-15.1.0-1.el7.noarch
  openstack-dashboard-theme-15.1.0-1.el7.noarch

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1842930/+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 1840288] Re: Trusts GET API leaks existence information to unauthorized users

[Morgan Fainberg]

Discussed in IRC[0] - conclusion is this is a Valid bug but there is no
reasonable attack vector (the data could be used in determining whom to
attempt to gain access to, but does not provide any means of direct
attack). The data is *NOT* intended to be public but is not really
explicitly private/privileged either. The API Contract and current
behavior is an acceptable (as long as it is documented in this bug)
behavior to leave.

This may still warrant an OSSN outlining that the data is available but
there is minimal or no risk.

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
/%23openstack-keystone.2019-08-16.log.html#t2019-08-16T21:36:28

** Changed in: keystone
   Status: In Progress => Won't Fix

-- 
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/1840288

Title:
  Trusts GET API leaks existence information to unauthorized users

Status in OpenStack Identity (keystone):
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The current implementation of the GET /v3/OS-TRUST/trusts/{trust_id}
  API leaks information about the existence of a trust to unauthorized
  users.

  If an authenticated user requests a trust that either does not exist
  or has no remaining uses, the returned response is a 404 regardless of
  whether the user is an admin or a trustor/trustee of the hypothetical
  (e.g. soft-deleted or used-up) trust. If the trust does exist but the
  user has no access to it, the returned response is a 403. If an
  attacker had some reasonable way of guessing or brute-forcing the UUID
  of a trust, they could use this leak to confirm its existence. A valid
  trust ID can then be used as part of a token request in combination
  with the trustee's credentials.

  The issue is here:

  
https://opendev.org/openstack/keystone/src/commit/5beddfaddbb4c59d7a24fa1d7ff534da4c69ddc5/keystone/api/trusts.py#L149-L150

  The current "identity:get_trust" default policy rule is "" which is
  all-permissive, and authorization is hardcoded in the trust controller
  code. To enforce the "only the trustor or trustee can GET this" rule,
  it does a lookup of the trust and doesn't catch a NotFound, thereby
  leaking it directly back to the requester.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1840288/+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 1837010] Re: [RFE] event callback dynamic loading

[Morgan Fainberg]

This isn't really a good idea. The way keystone's internal notification
framework is implemented, errors in that framework can leave the DB in
inconsistent states. If this were to be implemented any implementations
that are 3rd party could not reasonably be supported by the Keystone
team (upstream).

Currently it is possible to implement this feature by consuming the
CADF/Bus notifications.

** Changed in: keystone
   Status: New => Won't Fix

-- 
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/1837010

Title:
  [RFE] event callback dynamic loading

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  Currently, keystone uses event_callbacks only internal module
  registered
  
(https://github.com/openstack/keystone/blob/master/keystone/notifications.py#L258)

  I think it would be better to add external module's callbacks also for
  API using stevedore. It makes 3rd party logic which have to executed
  synchronously can be easily attached to core keystone logic. I was
  trying to find existed interface to add our logic without keystone
  change, but no one was there (Please let me know if there is)

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1837010/+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 1837061] [NEW] RFE: Application Credential API (CRUD) to 403 if app-cred auth method not enabled

[Morgan Fainberg]

Public bug reported:

There has been some confusion about the Application Credential API.
Specifically that application credentials can be created even if the
auth method is not enabled. The request is to make the Application
Credential API return a 403 (Forbidden) if the auth method is not
enabled.

The source of this request comes from mnaser based upon conversations in
the #openstack-infra channel.

http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
/%23openstack-keystone.2019-07-18.log.html#t2019-07-18T12:22:46

** Affects: keystone
 Importance: Wishlist
 Status: New


** Tags: rfe

** Tags added: rfe

** Changed in: keystone
   Importance: Undecided => Wishlist

-- 
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/1837061

Title:
  RFE: Application Credential API (CRUD) to 403 if app-cred auth method
  not enabled

Status in OpenStack Identity (keystone):
  New

Bug description:
  There has been some confusion about the Application Credential API.
  Specifically that application credentials can be created even if the
  auth method is not enabled. The request is to make the Application
  Credential API return a 403 (Forbidden) if the auth method is not
  enabled.

  The source of this request comes from mnaser based upon conversations
  in the #openstack-infra channel.

  http://eavesdrop.openstack.org/irclogs/%23openstack-keystone
  /%23openstack-keystone.2019-07-18.log.html#t2019-07-18T12:22:46

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1837061/+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 1816164] Re: RFE: Service Catalog Subsets by IDs

[Morgan Fainberg]

As discussed at the Denver PTG this is not really something we want to
handle. Breaking the catalog representation in the token could break
huge swaths of consumers and adding this as functionality is pretty low
priority vs. considering a new catalog form/mechanism.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1816164

Title:
  RFE: Service Catalog Subsets by IDs

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  (Original blueprint and specification was written by Adam Young)

  Allow the definition of subsets of the service catalog that can be
  referenced by ID. Use the ID as a way to shorthand the service
  catalog in tokens and other remote references.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1816164/+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 1819957] Re: Caching with stale data when a server disconnects due to network partition and reconnects

[Morgan Fainberg]

Keystone is fixed with oslo.cache fix, marked as invalid for keystone

** Changed in: keystone
   Status: Triaged => 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/1819957

Title:
  Caching with stale data when a server disconnects due to network
  partition and reconnects

Status in OpenStack Identity (keystone):
  Invalid
Status in keystonemiddleware:
  Triaged
Status in oslo.cache:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The flush_on_reconnect optional flag is not used. This can cause stale
  data to be utilized from a cache server that disconnected due to a
  network partition. This has security concerns as follows:

  1*  Password changes/user changes may be reverted for the cache TTL
  1a* User may get locked out if PCI-DSS is on and the password change happens 
during the network
  partition.
  2*  Grant changes may be reverted for the cache TTL
  3*  Resources (all types) may become "undeleted" for the cache TTL
  4*  Tokens (KSM) may become valid again during the cache TTL

  
  As noted in the python-memcached library:

  @param flush_on_reconnect: optional flag which prevents a
  scenario that can cause stale data to be read: If there's more
  than one memcached server and the connection to one is
  interrupted, keys that mapped to that server will get
  reassigned to another. If the first server comes back, those
  keys will map to it again. If it still has its data, get()s
  can read stale data that was overwritten on another
  server. This flag is off by default for backwards
  compatibility.

  The solution is to explicitly pass flush_on_reconnect as an optional
  argument. A concern with this model is that the memcached servers may
  be utilized by other tooling and may lose cache state (in the case the
  oslo.cache connection is the only thing affected by the network
  partitioning).

  This similarly needs to be addressed in pymemcache when it is utilized
  in lieu of python-memcached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1819957/+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 1819957] [NEW] Caching with stale data when a server disconnects due to network partition and reconnects

[Morgan Fainberg]

*** This bug is a security vulnerability ***

Public security bug reported:

The flush_on_reconnect optional flag is not used. This can cause stale
data to be utilized from a cache server that disconnected due to a
network partition. This has security concerns as follows:

1*  Password changes/user changes may be reverted for the cache TTL
1a* User may get locked out if PCI-DSS is on and the password change happens 
during the network
partition.
2*  Grant changes may be reverted for the cache TTL
3*  Resources (all types) may become "undeleted" for the cache TTL
4*  Tokens (KSM) may become valid again during the cache TTL


As noted in the python-memcached library:

@param flush_on_reconnect: optional flag which prevents a
scenario that can cause stale data to be read: If there's more
than one memcached server and the connection to one is
interrupted, keys that mapped to that server will get
reassigned to another. If the first server comes back, those
keys will map to it again. If it still has its data, get()s
can read stale data that was overwritten on another
server. This flag is off by default for backwards
compatibility.

The solution is to explicitly pass flush_on_reconnect as an optional
argument. A concern with this model is that the memcached servers may be
utilized by other tooling and may lose cache state (in the case the
oslo.cache connection is the only thing affected by the network
partitioning).

This similarly needs to be addressed in pymemcache when it is utilized
in lieu of python-memcached.

** Affects: keystone
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: New

** Affects: keystonemiddleware
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: New

** Affects: oslo.cache
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: New


** Tags: caching security

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

** Also affects: oslo.cache
   Importance: Undecided
   Status: New

** Tags added: caching security

** Changed in: keystone
   Importance: Undecided => High

** Changed in: keystonemiddleware
   Importance: Undecided => High

** Changed in: oslo.cache
   Importance: Undecided => High

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystonemiddleware
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: oslo.cache
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1819957

Title:
  Caching with stale data when a server disconnects due to network
  partition and reconnects

Status in OpenStack Identity (keystone):
  New
Status in keystonemiddleware:
  New
Status in oslo.cache:
  New

Bug description:
  The flush_on_reconnect optional flag is not used. This can cause stale
  data to be utilized from a cache server that disconnected due to a
  network partition. This has security concerns as follows:

  1*  Password changes/user changes may be reverted for the cache TTL
  1a* User may get locked out if PCI-DSS is on and the password change happens 
during the network
  partition.
  2*  Grant changes may be reverted for the cache TTL
  3*  Resources (all types) may become "undeleted" for the cache TTL
  4*  Tokens (KSM) may become valid again during the cache TTL

  
  As noted in the python-memcached library:

  @param flush_on_reconnect: optional flag which prevents a
  scenario that can cause stale data to be read: If there's more
  than one memcached server and the connection to one is
  interrupted, keys that mapped to that server will get
  reassigned to another. If the first server comes back, those
  keys will map to it again. If it still has its data, get()s
  can read stale data that was overwritten on another
  server. This flag is off by default for backwards
  compatibility.

  The solution is to explicitly pass flush_on_reconnect as an optional
  argument. A concern with this model is that the memcached servers may
  be utilized by other tooling and may lose cache state (in the case the
  oslo.cache connection is the only thing affected by the network
  partitioning).

  This similarly needs to be addressed in pymemcache when it is utilized
  in lieu of python-memcached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1819957/+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 1808059] Re: admin user should have service scoped admin role

[Morgan Fainberg]

Please do not try and make the NFV-feature specific bug something
different. Please open a new bug for features to bootstrap. Second,
there are bugs to open with the NFV plugins to support system scope.
This bug remains opinion.

** Changed in: keystone
   Status: New => Opinion

-- 
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/1808059

Title:
  admin user should have service scoped admin role

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  
  * Some 3rd party (NFV) require the admin user to have the admin role in the 
Default domain. 

  * Some deployers automatically add the admin user to the Default
  domain post deployment but it could probably be better to have
  keystone-manage bootstrap a domain with --bootstrap-domain-name.

  * We already assign user to project and create the Default domain in
  the bootstrapping procedure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1808059/+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 1808059] Re: admin user should have admin role in the Default domain

[Morgan Fainberg]

I disagree with this needing to be in bootstrap. The main reason is that
bootstrap is intended to simply get a deployment to a place where it can
be setup. Since this is only some 3rd party plugins for NFV, this is
something the deployment can choose to do.

Bootstrap is and always will be intended to be minimal functioning
Keystone. it is not intended for it to work out of the box for other
services. The point is to allow interaction with keystone and not
require steps such as "stand up keystone with a shared secret, setup
keystone via the api, restart keystone without shared secret".

Since "domain scoped" tokens are limited in use for setting up keystone,
it is not the direction to add more roles supplied by bootstrap.

In the future when system-scope is fully realized, bootstrap will likely
not even create a role on a project, but instead create a system-scoped
role for the admin user.

I am marking this as opinion. It's not something that fits within
bootstrap.

** Changed in: keystone
   Status: New => Opinion

-- 
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/1808059

Title:
  admin user should have admin role in the Default domain

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  
  * Some 3rd party (NFV) require the admin user to have the admin role in the 
Default domain. 

  * Some deployers automatically add the admin user to the Default
  domain post deployment but it could probably be better to have
  keystone-manage bootstrap a domain with --bootstrap-domain-name.

  * We already assign user to project and create the Default domain in
  the bootstrapping procedure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1808059/+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 1802136] Re: RFE: Keystone SQL backend (and `user_create` API) should support prehashed passwords

[Morgan Fainberg]

Discussed this with the Keystone core team and we came to the following
conclusions:

* This is prone to errors. It is easy to create an unusable password and
short of also submitting the plaintext password keystone can't ensure
the hash, ident, and metadata is sane.

* This doesn't meaningfully reduce the surface area of attack. Many CMS
tools have integrations with things such as Vault. This prevents the
need to store plaintext passwords for CMS purposes. For consumers of the
API, they still need access to the plaintext password form. The target
is equally split between the scripts/humans/tools accessing the API as
Keystone's create user mechanism. The create_user API is the least
common use of the password. If the users/scripts/tools are using vault
(or similar tools), the CMS to configure keystone should also lean on
those tools.

Generally keystone does not trust externally supplied information it
historically has considered itself authoritative for.

The alternative options that readily come to mind are:

* Deploy LDAP and manage passwords directly in LDAP / separate from
Keystone.

* Deploy an use a tool such as Vault for housing the passwords that both
consumers and CMS would use for creation/maintenance.


At this time I'm marking this as Invalid as it doesn't align with the direction 
of the project. 

** Changed in: 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/1802136

Title:
  RFE: Keystone SQL backend (and `user_create` API) should support
  prehashed passwords

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Keystone should allow pre-hashed passwords at user creation. This
  change would allow passwords to be stored in scripts without storing
  them in plaintext. This would improve security

  The same report was filed for the LDAP backend here:
  https://bugs.launchpad.net/keystone/+bug/1400443

  It was refused because there are various ways this can go wrong with
  LDAP. Would this change get accepted if I implemented it for the SQL
  backend or is there anything wrong with this suggestion?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1802136/+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 1807751] [NEW] Resource Options Implemented for all Resource Types

[Morgan Fainberg]

Public bug reported:

Resource Options have been built for Users (used for PCI-DSS work). The
functionality needs to be expanded to all resource types (projects,
domains, roles, etc) for future looking work. The future looking work
will include things such as default MFA Rules, restrictions on origin
for logging into a given user, user scoped to a domain, user scoped to a
project, user scoped to system, etc.

It has been a desire to have the same mechanism(s) for the resource
options to be available outside of just users. This bug is meant to
track that work.

** Affects: keystone
 Importance: Wishlist
 Assignee: Morgan Fainberg (mdrnstm)
 Status: Triaged

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Wishlist

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1807751

Title:
  Resource Options Implemented for all Resource Types

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Resource Options have been built for Users (used for PCI-DSS work).
  The functionality needs to be expanded to all resource types
  (projects, domains, roles, etc) for future looking work. The future
  looking work will include things such as default MFA Rules,
  restrictions on origin for logging into a given user, user scoped to a
  domain, user scoped to a project, user scoped to system, etc.

  It has been a desire to have the same mechanism(s) for the resource
  options to be available outside of just users. This bug is meant to
  track that work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1807751/+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 1801778] Re: Keystone circular reference on OPTIONS

[Morgan Fainberg]

Marking this as invalid in Triple-O, there is an underlying issue in
keystone causing the "recursive" error. The OPTIONS bug solved the issue
directly.

** Changed in: tripleo
   Status: Triaged => Invalid

** Summary changed:

- Keystone circular reference on OPTIONS
+ Keystone 500 on OPTIONS

** Changed in: keystone
Milestone: None => stein-1

-- 
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/1801778

Title:
  Keystone 500 on OPTIONS

Status in OpenStack Identity (keystone):
  Fix Released
Status in tripleo:
  Invalid

Bug description:
  When trying to authenticate against
  https://192.168.24.2/keystone/v3/auth/tokens with CORS (the OPTIONS
  req), I get a 500 error.  Inside the keystone container, the logs have
  this:

  018-11-05 19:01:33.396 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Policy Enforcement 
Cred Data `identity:validate_token creds(service_project_id=None, 
service_user_id=None, service_user_domain_id=None, 
service_project_domain_id=None, trustor_id=None, user_domain_id=default, 
domain_id=None, trust_id=None, project_domain_id=default, service_roles=[], 
group_ids=[], user_id=f2ff68e4483344268c959e3dcf6b8b45, roles=[u'member', 
u'reader', u'admin'], system_scope=None, trustee_id=None, domain_name=None, 
is_admin_project=True, token=*** (audit_id=RyLKr6cyRLC2p6oV5-52Cg, 
audit_chain_id=[u'RyLKr6cyRLC2p6oV5-52Cg']) at 0x7f371cf0dc50>, 
project_id=53568db657e445a49d40a25c4a7fdd42)` enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:418
  2018-11-05 19:01:33.396 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Policy Enforcement 
Target Data `identity:validate_token => 
target(target.token.user.domain.id=default, 
target.token.user_id=5f351e642aa54a1abc20726ffe9bcc04)` enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:426
  2018-11-05 19:01:33.415 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Authorization granted 
enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:432
  2018-11-05 19:01:33.425 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.
  2018-11-05 19:01:33.433 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.
  2018-11-05 19:01:33.447 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.

  
  This is blocking the tripleo-ui because I can't log in.  It's a brand new 
install using reproducer in RDO cloud.  The deployment finished successfully.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1801778/+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 1801778] Re: Keystone circular reference on OPTIONS

[Morgan Fainberg]

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

** Changed in: keystone
   Status: New => Confirmed

** Changed in: keystone
   Status: Confirmed => Triaged

** Changed in: keystone
   Importance: Undecided => Critical

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1801778

Title:
  Keystone circular reference on OPTIONS

Status in OpenStack Identity (keystone):
  In Progress
Status in tripleo:
  Triaged

Bug description:
  When trying to authenticate against
  https://192.168.24.2/keystone/v3/auth/tokens with CORS (the OPTIONS
  req), I get a 500 error.  Inside the keystone container, the logs have
  this:

  018-11-05 19:01:33.396 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Policy Enforcement 
Cred Data `identity:validate_token creds(service_project_id=None, 
service_user_id=None, service_user_domain_id=None, 
service_project_domain_id=None, trustor_id=None, user_domain_id=default, 
domain_id=None, trust_id=None, project_domain_id=default, service_roles=[], 
group_ids=[], user_id=f2ff68e4483344268c959e3dcf6b8b45, roles=[u'member', 
u'reader', u'admin'], system_scope=None, trustee_id=None, domain_name=None, 
is_admin_project=True, token=*** (audit_id=RyLKr6cyRLC2p6oV5-52Cg, 
audit_chain_id=[u'RyLKr6cyRLC2p6oV5-52Cg']) at 0x7f371cf0dc50>, 
project_id=53568db657e445a49d40a25c4a7fdd42)` enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:418
  2018-11-05 19:01:33.396 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Policy Enforcement 
Target Data `identity:validate_token => 
target(target.token.user.domain.id=default, 
target.token.user_id=5f351e642aa54a1abc20726ffe9bcc04)` enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:426
  2018-11-05 19:01:33.415 230 DEBUG keystone.common.rbac_enforcer.enforcer 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] RBAC: Authorization granted 
enforce_call 
/usr/lib/python2.7/site-packages/keystone/common/rbac_enforcer/enforcer.py:432
  2018-11-05 19:01:33.425 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.
  2018-11-05 19:01:33.433 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.
  2018-11-05 19:01:33.447 230 ERROR keystone.assignment.core 
[req-def53dc3-9ac5-4470-9d21-7f737534dc90 f2ff68e4483344268c959e3dcf6b8b45 
53568db657e445a49d40a25c4a7fdd42 - default default] Circular reference found 
role inference rules - 5be439ef59e949b28f7e38599a828374.

  
  This is blocking the tripleo-ui because I can't log in.  It's a brand new 
install using reproducer in RDO cloud.  The deployment finished successfully.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1801778/+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 1642988] Re: Optionally encode project IDs in fernet tokens

[Morgan Fainberg]

Revisiting to mark as wont fix after reading through it. This is a
misunderstanding of the fernet packing and that the token payload is
intended to be a blackbox and decoded/expanded by keystone itself.

ID formats (dashes, no dashes, etc) are the purview of keystone.

** Changed in: keystone
   Status: Incomplete => Won't Fix

-- 
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/1642988

Title:
  Optionally encode project IDs in fernet tokens

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  The proposal is to allow an operator to disable the encoding of the
  project_id in fernet via a configuration setting. In this way
  operators that have project ids in a different uuid format than the
  hex format, can opt-out for the try/catch conversion with uuid
  resulting in a valid encoding/decoding of this information inside the
  fernet token. The configuration setting will be disabled by default,
  not modifying the default behavior.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1642988/+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 1553224] Re: keystone-manage bootstrap assumes user-project role assignment

[Morgan Fainberg]

This is not really in the plans. Bootstrap is meant to get you to a
place you can setup the rest of the system via the APIs. It is
intentionally very narrow. Marking as wont fix.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1553224

Title:
  keystone-manage bootstrap assumes user-project role assignment

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  keystone-manage bootstrap creates a role assignment for the specified
  user on the specified project. That is one way someone might want to
  do bootstrapping, but there are good reasons a user may need/prefer:

  1) user-domain role assignment... e.g. Switching identity drivers for
  an existing single-domain multi-project configuration. Bootstrapping
  is needed to configure the initial role assignments for the new
  driver. Since the "cloud admin" concept is not essential for single-
  domain environments, it may very well not be configured, yet the
  initial role assignment needs to grant someone the ability to create
  additional role assignments for all projects in the domain. This would
  be a domain admin.

  2) group-project role assignment... e.g. Where the desired end result
  is for a group-project role assignment on the cloud admin project, it
  makes more sense to allow that to be created directly (which could be
  done without even knowing the password of any user in that group) than
  to require bootstrapping of a single user and then using their account
  to create the group assignment and delete the bootstrapped assignment.

  3) group-domain role assignment... e.g. combination of #1 and #2

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1553224/+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 1498556] Re: Reasonable assumptions concerning domain references

[Morgan Fainberg]

Keystone no longer has v2/v3 split. V3 is always explicit about domain
membership (as per the description of the bug). Moving this to "Wont
Fix" for the server.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1498556

Title:
  Reasonable assumptions concerning domain references

Status in OpenStack Identity (keystone):
  Won't Fix
Status in keystoneauth:
  Won't Fix
Status in keystonemiddleware:
  Invalid
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Triaged
Status in OpenStack SDK:
  New

Bug description:
  There are 3 primary places where client can be configured to reference
  domains. The actual parameter names vary based on the configuration
  interface (a function's arguments, the env, CLI arguments, etc), but
  I'll use environment variables here for the sake of general
  familiarity:

  1. OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME: Used for specifying the
  domain which owns the authenticating user.

  2. OS_PROJECT_DOMAIN_ID and OS_PROJECT_DOMAIN_NAME: Used for
  specifying the domain which owns the desired project scope.

  3. OS_DOMAIN_ID and OS_DOMAIN_NAME: Used for specifying the desired
  domain scope.

  On the service side, a "default domain" is created which, by default,
  looks like:

    id="default"

    name="Default"

  The default domain is exclusively used on the service-side for scoping
  v2 operations, which are not domain-aware, in the broader multi-domain
  namespace exposed by v3. The default domain's ID is mutable via
  configuration (CONF.identity.default_domain_id) and the domain name is
  mutable via the API (PATCH /v3/domains/default, for example).
  Generally, deployers should not have any reason to change the default
  domain ID from it's default value of "default".

  Both (1) and (2) refer to domains that provide context to other
  configuration options. In single domain deployments, or deployments
  wherein most users and projects exist in the "default domain", it
  would benefit the user experience to assume that the user's and
  project exist in the default domain. Specifically, this means that
  users have fewer (if any) additional configuration options to set when
  migrating from v2 to v3, easing adoption of v3 overall. Deployments
  that opt into more complex multi-domain arrangement are thus opting
  into consuming more complex configuration options on the client side
  (they must specify their non-default domains explicitly).

  On (3), these values should always default to null values, and no
  assumptions should ever be made about their values. If a non-null
  default were to be set, then that means that the client should always
  try to obtain a domain-scoped token which is almost never the intended
  behavior.

  There are three approaches to implementing this behavior. Two of them
  are obvious at a high level, but easily fragile.

  If OS_USER_DOMAIN_ID defaults to "default" to match the default
  CONF.identity.default_domain_id value, then whenever the user sets a
  OS_USER_DOMAIN_NAME, the OS_USER_DOMAIN_ID *must* be ignored in favor
  of using the specified domain name. This is a potentially unreliable
  behavior, as domain IDs are immutable and are thus more preferable as
  reliable references.

  If OS_USER_DOMAIN_NAME defaults to "Default" to match the default
  domain name value, then whenever the user sets a OS_USER_DOMAIN_ID,
  the OS_USER_DOMAIN_NAME *must* be ignored in favor of using the
  specified domain ID. This is a potentially unreliable behavior, as
  assuming that the default domain still has a default domain name of
  "Default" is fragile considering that it's mutable through the regular
  HTTP API (a deployer will inevitably change it, thus breaking the
  client's default behavior). This approach is fragile.

  The third option is a combination of the above two approaches, and
  must happen at the "last minute" before requests are issued to
  keystone (after all possible sources of configuration have been
  handled). That is, both OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME
  default to null values on the surface. When an actual HTTP request is
  built, normal configuration precedence takes place (for example, in a
  CLI client):

  1) If an --os-user-domain-id is specified, then that is used, ignoring
  --os-user-domain-name, OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.
  This is the most specific, reliable configuration option available. A
  warning could be issued about the ignored values being discarded to
  communicate this sequence of precedence.

  2) If an --os-user-domain-name is specified, then that is used,
  ignoring OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.

  3) If an OS_USER_DOMAIN_ID, then that is used, ignoring
  OS_USER_DOMAIN_NAME.

  4) If an OS_USER_DOMAIN_NAME, then that is used.

  5) Else, 

[Yahoo-eng-team] [Bug 1180136] Re: Dependency injection framework is constructing the object first and then injecting the dependency which is incorrect

[Morgan Fainberg]

Dependency Injection was removed/reworked. This is no longer an issue.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1180136

Title:
  Dependency injection framework is constructing the object first and
  then injecting the dependency which is incorrect

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  Dependency injection framework is constructing the object first and
  then injecting the dependency which is incorrect.

  def requires(*dependencies):
  """Inject specified dependencies from the registry into the instance."""
  def wrapper(self, *args, **kwargs):
  """Inject each dependency from the registry."""
  self.__wrapped_init__(*args, **kwargs)   --> 
Constructs object First

  for dependency in self._dependencies:--> 
Inject dependency  Second
  if dependency not in REGISTRY:
  raise UnresolvableDependencyException(dependency)
  setattr(self, dependency, REGISTRY[dependency])

  It would be better to inject the dependency first and then construct
  the object, so that the dependency is available during object
  construction.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1180136/+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 1623117] Re: Prevent keystone from serving requests when schema or data migrations are not up to date

[Morgan Fainberg]

This is in violation of the rolling upgrade plans. Marking as "wont fix"

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1623117

Title:
  Prevent keystone from serving requests when schema or data migrations
  are not up to date

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  There are three scenarios during a rolling upgrade process where we
  could prevent operators from doing the "wrong thing" (doing things out
  of order):

  1) Operators running code from the next release before `keystone-
  manage db_sync --expand` has been run: If you run the next release
  before --expand is run, then you'll surely end up with fatal query
  errors as columns and tables won't exist that the app thinks should
  exist.

  2) (the scary one) Operators running code from the next release before
  `keystone-manage db_sync --migrate` has been run: If you run the next
  release before --migrate is run, then any number of different types of
  failures are possible due to unpopulated columns & tables, including a
  risk of data loss as the new release tries to update records that it
  perceives to be unpopulated, which might propagate to the legacy
  schema during UPDATE operations, for example.

  3) Operators running code from the previous release after `keystone-
  manage db_sync --contract` has been run: As in case (1), this may
  result in fatal query errors, but also presents a risk of introducing
  data inconsistency, as the legacy schema might not have a "full
  understanding" of the new schema, as would be the case with additive
  schema changes. The legacy application would no longer have triggers
  to rely on, so consequences would mostly be dependent on the default
  values of columns, constraints, etc.

  The second case worries me, as it's the most likely scenario where
  operators might not realize what's going on until it's too late.

  To prevent all of these scenarios, I think the application should
  check at startup to ensure that the expand and data migration
  repositories both match a minimum value (specifically, the most recent
  migration in the application's respective repositories).

  Doing the same sort of check at startup for the contract repo would be
  more difficult, as it'd be entirely dependent on when you last
  upgraded (whether it be last stable/* release or master at any point),
  so I'd like to leave that out of scope here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1623117/+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 1660603] Re: Difference in Implied Roles check API return code

[Morgan Fainberg]

Marking as "invalid" now.

** Changed in: keystone
   Status: Confirmed => 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/1660603

Title:
  Difference in Implied Roles check API return code

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  The Implied Roles check API (HEAD
  /v3/roles//implies/) returns 200 in Ubuntu Trusty
  and 204 in Ubuntu Xenial, check the jobs results at [1] (both running
  latest master):

  - example of output in ubuntu-trusty job:

  http://logs.openstack.org/82/426882/1/check/gate-tempest-dsvm-neutron-
  full-ubuntu-trusty/d4f9ec8/console.html#_2017-01-30_20_11_54_895227

  This bug is not related if returning a 200 or 204 is correct for the
  given API, but related to the difference between two Ubuntu versions.
  Additionally, this specific API doesn't use the "wsgi.render_response"
  method [2] - others APIs that use this method (check grant, for
  example) don't have this problem.

  [1] https://review.openstack.org/#/c/426882/
  [2] 
https://github.com/openstack/keystone/blob/aeb51c84bb92d02715208aa8435aa3fd36564c72/keystone/assignment/controllers.py#L518-L519

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1660603/+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 1797876] Re: Default values for registered limit allows to set negative value

[Morgan Fainberg]

Marking as wont fix, the -1 is correct behavior for "no limit".

** Changed in: keystone
   Status: In Progress => Won't Fix

-- 
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/1797876

Title:
  Default values for registered limit allows  to set  negative value

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  In registered limit as well as project limit user can create and set
  negative default and resource limit. Limits set should be positive.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1797876/+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 1780164] Re: httpd leaks open files

[Morgan Fainberg]

We should fix keystoneclient. KeystoneAuth is not doing anything wrong
here. I am against a "temp hack" like this. Secondarily, please submit
this patch to gerrit at review.openstack.org so that it can be
considered. Posting patches here is unlikely to be seen as
easily/readily.

** Changed in: keystoneauth
   Status: Confirmed => Won't Fix

** Also affects: python-keystoneclient
   Importance: Undecided
   Status: New

** Changed in: python-keystoneclient
   Status: New => Confirmed

** Changed in: python-keystoneclient
   Importance: Undecided => Medium

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

Title:
  httpd leaks open files

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in keystoneauth:
  Won't Fix
Status in python-keystoneclient:
  Confirmed

Bug description:
  horizon version 13.0.0-1.el7 (Queens) on centos  7.4.1708

  After some time working on the dashboard, it stops working and throw
  this error in the error log

  [Wed Jul 04 22:49:33.744241 2018] [:error] [pid 23924] [remote
  10.144.187.237:52] IOError: [Errno 24] Too many open files:
  '/usr/share/openstack-
  dashboard/openstack_dashboard/templates/500.html'

  if we check the open files of this process 23924

   ls -l /proc/23924/fd | wc -l
  1023

  even if we increase the nofile limit of this process, it doesn't help as the 
open files is always increasing
  the problem is cleared if we restart the httpd process, but then the open 
files will increase again

  how to reproduce

  1- login to the dashboard
  2- get the pid from the error_log file
  [Wed Jul 04 22:50:58.620832 2018] [:error] [pid 23924] INFO 
openstack_auth.forms Login successful for user "demo" using domain "default"
  3- browse the dashboard different menus, specially the network topology tab
  4- monitor the open files no. with ls -l /proc//fd | wc -l

  observation
  the no. is always increasing

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1780164/+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 1498556] Re: Reasonable assumptions concerning domain references

[Morgan Fainberg]

** Changed in: keystoneauth
   Status: Triaged => Won't Fix

-- 
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/1498556

Title:
  Reasonable assumptions concerning domain references

Status in OpenStack Identity (keystone):
  Triaged
Status in keystoneauth:
  Won't Fix
Status in keystonemiddleware:
  Invalid
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Triaged
Status in OpenStack SDK:
  New

Bug description:
  There are 3 primary places where client can be configured to reference
  domains. The actual parameter names vary based on the configuration
  interface (a function's arguments, the env, CLI arguments, etc), but
  I'll use environment variables here for the sake of general
  familiarity:

  1. OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME: Used for specifying the
  domain which owns the authenticating user.

  2. OS_PROJECT_DOMAIN_ID and OS_PROJECT_DOMAIN_NAME: Used for
  specifying the domain which owns the desired project scope.

  3. OS_DOMAIN_ID and OS_DOMAIN_NAME: Used for specifying the desired
  domain scope.

  On the service side, a "default domain" is created which, by default,
  looks like:

    id="default"

    name="Default"

  The default domain is exclusively used on the service-side for scoping
  v2 operations, which are not domain-aware, in the broader multi-domain
  namespace exposed by v3. The default domain's ID is mutable via
  configuration (CONF.identity.default_domain_id) and the domain name is
  mutable via the API (PATCH /v3/domains/default, for example).
  Generally, deployers should not have any reason to change the default
  domain ID from it's default value of "default".

  Both (1) and (2) refer to domains that provide context to other
  configuration options. In single domain deployments, or deployments
  wherein most users and projects exist in the "default domain", it
  would benefit the user experience to assume that the user's and
  project exist in the default domain. Specifically, this means that
  users have fewer (if any) additional configuration options to set when
  migrating from v2 to v3, easing adoption of v3 overall. Deployments
  that opt into more complex multi-domain arrangement are thus opting
  into consuming more complex configuration options on the client side
  (they must specify their non-default domains explicitly).

  On (3), these values should always default to null values, and no
  assumptions should ever be made about their values. If a non-null
  default were to be set, then that means that the client should always
  try to obtain a domain-scoped token which is almost never the intended
  behavior.

  There are three approaches to implementing this behavior. Two of them
  are obvious at a high level, but easily fragile.

  If OS_USER_DOMAIN_ID defaults to "default" to match the default
  CONF.identity.default_domain_id value, then whenever the user sets a
  OS_USER_DOMAIN_NAME, the OS_USER_DOMAIN_ID *must* be ignored in favor
  of using the specified domain name. This is a potentially unreliable
  behavior, as domain IDs are immutable and are thus more preferable as
  reliable references.

  If OS_USER_DOMAIN_NAME defaults to "Default" to match the default
  domain name value, then whenever the user sets a OS_USER_DOMAIN_ID,
  the OS_USER_DOMAIN_NAME *must* be ignored in favor of using the
  specified domain ID. This is a potentially unreliable behavior, as
  assuming that the default domain still has a default domain name of
  "Default" is fragile considering that it's mutable through the regular
  HTTP API (a deployer will inevitably change it, thus breaking the
  client's default behavior). This approach is fragile.

  The third option is a combination of the above two approaches, and
  must happen at the "last minute" before requests are issued to
  keystone (after all possible sources of configuration have been
  handled). That is, both OS_USER_DOMAIN_ID and OS_USER_DOMAIN_NAME
  default to null values on the surface. When an actual HTTP request is
  built, normal configuration precedence takes place (for example, in a
  CLI client):

  1) If an --os-user-domain-id is specified, then that is used, ignoring
  --os-user-domain-name, OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.
  This is the most specific, reliable configuration option available. A
  warning could be issued about the ignored values being discarded to
  communicate this sequence of precedence.

  2) If an --os-user-domain-name is specified, then that is used,
  ignoring OS_USER_DOMAIN_ID, and OS_USER_DOMAIN_NAME.

  3) If an OS_USER_DOMAIN_ID, then that is used, ignoring
  OS_USER_DOMAIN_NAME.

  4) If an OS_USER_DOMAIN_NAME, then that is used.

  5) Else, assume the domain id="default".

  Everything above referencing a OS_USER_DOMAIN_ID + OS_USER_DOMAIN_NAME
  applies equally to OS_PROJECT_DOMAIN_ID + 

[Yahoo-eng-team] [Bug 1659053] Re: use uuids with pycadf

[Morgan Fainberg]

** Changed in: pycadf
   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/1659053

Title:
  use uuids with pycadf

Status in OpenStack Identity (keystone):
  Fix Released
Status in pycadf:
  Fix Released

Bug description:
  pycadf warnings are plentiful in keystone tests: UserWarning: Invalid uuid. 
To ensure interoperability, identifiersshould be a valid uuid.
warnings.warn('Invalid uuid. To ensure interoperability, identifiers'

  
  Be sure keystone is providing uuids appropriately.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1659053/+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 1699060] Re: Impossible to define policy rule based on domain ID

[Morgan Fainberg]

@Ben, this is nothing to do with oslo-policy. it has to do with the
values passed to oslo-policy in the creds dict. If the creds dict does
not have domain-id populated in it, you can't enforce on it.

** Changed in: oslo.policy
   Status: Incomplete => Invalid

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

Title:
  Impossible to define policy rule based on domain ID

Status in Glance:
  New
Status in OpenStack Heat:
  Triaged
Status in Manila:
  Opinion
Status in neutron:
  Opinion
Status in OpenStack Compute (nova):
  Opinion
Status in oslo.policy:
  Invalid
Status in watcher:
  Opinion

Bug description:
  We have common approach to set rules for each API using policy.json file.
  And for the moment, it is not possible to use "domain_id" in policy rules,
  only "project_id" and "user_id". It becomes very important because Keystone 
API v3 is used more and more.
  The only service that supports rules with "domain_id" is Keystone itself.

  As a result we should be able to use following rules:
  "admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s",
  "domain_owner": "domain_id:%(domain_id)s",

  like this:

  "volume:get": "rule:domain_owner",

  or

  "volume:get": "rule:admin_or_domain_owner",

  Right now, we always get 403 error having such rules.

  Related mail-list thread: https://openstack.nimeyo.com/115438
  /openstack-dev-all-policy-rules-for-apis-based-on-domain_id

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1699060/+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 1687593] Re: Create OAUTH request token gives 401 error when request url is admin endpoint

[Morgan Fainberg]

** Changed in: python-keystoneclient
   Status: In Progress => Won't Fix

-- 
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/1687593

Title:
  Create OAUTH request token gives 401 error when request url is admin
  endpoint

Status in OpenStack Identity (keystone):
  Fix Committed
Status in OpenStack Identity (keystone) newton series:
  Won't Fix
Status in OpenStack Identity (keystone) ocata series:
  Won't Fix
Status in python-keystoneclient:
  Won't Fix

Bug description:
  Create request token API returns 401 error when the request URL is
  admin endpoint.

  Error scenario:
  URL used to generate OAUTH signature and for POST request is Keystone admin 
endpoint
  http:///identity_admin/v3/OS-OAUTH1/request_token

  Working scenario:
  When the URL used to generate OAUTH signature is public endpoint, then the 
response is 201. 
  http:///identity/v3/OS-OAUTH1/request_token

  Endpoints in devstack for identity:
  ocata@ocata-VirtualBox:~/devstack$ openstack endpoint list | grep identity
  | 549f73e17b0e471e95176bb508561bb3 | RegionOne | keystone | identity  
| True| internal  | http://192.168.56.101/identity|
  | 739cda51666f4ab197241beac5c5c14c | RegionOne | keystone | identity  
| True| admin | http://192.168.56.101/identity_admin  |
  | a0eb39c0ecff46c3b61bc6184c42bc13 | RegionOne | keystone | identity  
| True| public| http://192.168.56.101/identity

  
  Steps to reproduce the problem:

  Run the python script in the below link (by changing the necessary 
credentials and IP address)
  https://pastebin.com/AqL9674n

  If #L38 is modified to public endpoint (http:///identity/v3/OS-OAUTH1/request_token), the status code is 201.

  Seems like Keystone code verifies the OAUTH signature using Public
  endpoint irrespective of the request URL.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1687593/+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 1710329] Re: support for chinese name to show

[Morgan Fainberg]

Is this something in the Keystone Server? this doesn't seem to be KSC
specific.

** Changed in: python-keystoneclient
   Status: In Progress => Incomplete

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

-- 
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/1710329

Title:
  support for chinese name to show

Status in OpenStack Identity (keystone):
  New
Status in python-keystoneclient:
  Incomplete

Bug description:
  I create a project with a chinese name, then get the project with the
  name.

  openstack --debug  project show 中文

  REQ: curl -g -i -X GET http://10.43.166.109:35357/v2.0/tenants -H 
"User-Agent: python-keystoneclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}fe395e6a71aed0df6b06ef64cde70a93e3338f7b"
  "GET /v2.0/tenants HTTP/1.1" 200 584
  RESP: [200] Content-Length: 584 Vary: X-Auth-Token Connection: keep-alive 
Date: Sat, 23 Jun 2001 02:24:46 GMT Content-Type: application/json 
X-Openstack-Request-Id: req-5e4c498e-a474-4fa1-9614-b350d60d036a 

  /usr/lib/python2.7/site-packages/keystoneclient/base.py:283: UnicodeWarning: 
Unicode equal comparison failed to convert both arguments to Unicode - 
interpreting them as being unequal
    for (attr, value) in searches):
  No tenant with a name or ID of '中文' exists.

  my env variable is as:
  export OS_USERNAME=admin
  export OS_PASSWORD=keystone
  export OS_AUTH_URL=http://10.43.166.109:5000/v2.0
  export OS_TENANT_NAME=admin
  export OS_REGION_NAME=RegionOne

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1710329/+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 1266962] Re: Remove set_time_override in timeutils

[Morgan Fainberg]

removed keystonemiddleware as LP will timeout when trying to update.

** No longer affects: keystonemiddleware

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

Title:
  Remove set_time_override in timeutils

Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in gantt:
  New
Status in Glance:
  Fix Released
Status in OpenStack Heat:
  Triaged
Status in Ironic:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Manila:
  Fix Released
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in oslo.utils:
  Triaged
Status in python-keystoneclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in rack:
  In Progress
Status in Sahara:
  Invalid
Status in tuskar:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  set_time_override was written as a helper function to mock utcnow in
  unittests.

  However we now use mock or fixture to mock our objects so
  set_time_override has become obsolete.

  We should first remove all usage of set_time_override from downstream
  projects before deleting it from oslo.

  List of attributes and functions to be removed from timeutils:
  * override_time
  * set_time_override()
  * clear_time_override()
  * advance_time_delta()
  * advance_time_seconds()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1266962/+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 1317302] Re: pki_setup shouldn't be required to check revocations

[Morgan Fainberg]

Revocations are no longer exposed with keystone. Marking this bug as
invalid.

** Changed in: keystonemiddleware
   Status: Triaged => Won't Fix

** Changed in: keystonemiddleware
   Status: Won't Fix => 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/1317302

Title:
  pki_setup shouldn't be required to check revocations

Status in OpenStack Identity (keystone):
  Fix Released
Status in keystonemiddleware:
  Invalid

Bug description:
  
  With the fix for bug 1312858 , auth_token can validate UUID tokens or hashed 
PKI tokens against the revocation list. But in order to use this in a setting 
where only UUID tokens are being used, the server still needs to have pki_setup 
run. We should be able to check UUID tokens against the revocation list even 
when pki_setup hasn't been done.

  The reason pki_setup has to be done is that the revocation list is
  signed using CMS. The auth_token middleware only accepts the signed
  format for the revocation list.

  The proposed solution is to change the auth_token middleware to also
  accept a revocation list that's not signed. If it's not signed, then
  the PKI certificates aren't required.

  The keystone server will be changed to allow configuring it such that
  the revocation list will be sent as an unencrypted JSON object that
  the auth_token middleware can now accept.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1317302/+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 1440493] Re: Crash with python-memcached==1.5.4

[Morgan Fainberg]

marking as invalid for ksm.

** Changed in: keystonemiddleware
   Status: In Progress => 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/1440493

Title:
  Crash with python-memcached==1.5.4

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in keystonemiddleware:
  Invalid

Bug description:
  There's some magic going on at line:
  
https://github.com/openstack/keystone/blob/2014.2.2/keystone/common/cache/_memcache_pool.py#L46

  This magic is broken due to the fact that python-memcached added a super(...) 
initalization at
  https://github.com/linsomniac/python-memcached/blob/master/memcache.py#L218
  
https://github.com/linsomniac/python-memcached/commit/45403325e0249ff0f61d6ae449a7daeeb7e852e5

  Due to this change, keystone can no longer work with the latest
  python-memcached version:

  Traceback (most recent call last):
File ""keystone/common/wsgi.py", line 223, in __call__
  result = method(context, **params)
File ""keystone/identity/controllers.py", line 76, in create_user
  self.assignment_api.get_project(default_project_id)
File ""dogpile/cache/region.py", line 1040, in decorate
  should_cache_fn)
File ""dogpile/cache/region.py", line 651, in get_or_create
  async_creator) as value:
File ""dogpile/core/dogpile.py", line 158, in __enter__
  return self._enter()
File ""dogpile/core/dogpile.py", line 91, in _enter
  value = value_fn()
File ""dogpile/cache/region.py", line 604, in get_value
  value = self.backend.get(key)
File ""dogpile/cache/backends/memcached.py", line 149, in get
  value = self.client.get(key)
File ""keystone/common/cache/backends/memcache_pool.py", line 35, in 
_run_method
  with self.client_pool.acquire() as client:
File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
  return self.gen.next()
File ""keystone/common/cache/_memcache_pool.py", line 97, in acquire
  conn = self.get(timeout=self._connection_get_timeout)
File ""eventlet/queue.py", line 293, in get
  return self._get()
File ""keystone/common/cache/_memcache_pool.py", line 155, in _get
  conn = ConnectionPool._get(self)
File ""keystone/common/cache/_memcache_pool.py", line 120, in _get
  conn = self._create_connection()
File ""keystone/common/cache/_memcache_pool.py", line 149, in 
_create_connection
  return _MemcacheClient(self.urls, **self._arguments)
File ""memcache.py", line 228, in __init__
  super(Client, self).__init__()
  TypeError: super(type, obj): obj must be an instance or subtype of type

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1440493/+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 1795800] Re: Username enumeration via response timing difference

[Morgan Fainberg]

I don't know how we'll address this. Realistically, I think this is
going to have to be marked as invalid/wont fix/opinion. I'm going to
mark it as wont fix, we can circle back on it if there is more
discussion to be had.

** Changed in: keystone
   Status: New => Won't Fix

-- 
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/1795800

Title:
  Username enumeration via response timing difference

Status in OpenStack Identity (keystone):
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  The response times for POST /v3/auth/tokens are significantly higher
  for valid usernames compared to those of invalid ones, making it
  possible to enumerate users on the system.

  Examples:

  # For invalid username
  + Request
  POST /v3/auth/tokens HTTP/1.1
  Host: hostname:5000
  Connection: close
  Content-Length: 141
  Content-Type: application/json

  {"auth":{"identity":{"methods":
  ["password"],"password":{"user":{"name":
  "nonexisting","domain":{"name": "Default"},"password":
  "devstacker"}

  + Response Time: <150ms

  # For valid username ('admin' in this case)
  + Request
  POST /v3/auth/tokens HTTP/1.1
  Host: hostname:5000
  Connection: close
  Content-Length: 139
  Content-Type: application/json

  {"auth":{"identity":{"methods":
  ["password"],"password":{"user":{"name": "admin","domain":{"name":
  "Default"},"password": "devstacker"}

  + Response time: >600ms

  # Tested version
  v3.8

  [UPDATE 3 Oct 2018 5:01 AEST]
  Looks like it's also possible to enumerate for valid "domain" too. There're 2 
ways that I can see:
  * With valid username: use the above user enum bug to guess the valid 
username, then brute the "domain" parameter. Response times are significantly 
higher for valid compared to invalid domains.
  * Without valid username: get a baseline response time using invalid username 
AND invalid domain name. Bruteforce the "domain" param until the response time 
hits an average high. For me invalid domain falls in the 90-100ms range whereas 
valid ones show 100+ms. This one looks a bit more obscure i.e. timing 
difference is not as distinguishable, but should still be recognisable with a 
good sample size.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1795800/+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 1649616] Re: Keystone Token Flush job does not complete in HA deployed environment

[Morgan Fainberg]

newton is EOL

** Changed in: keystone/newton
   Status: In Progress => Won't Fix

** Changed in: keystone/ocata
   Status: In Progress => 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/1649616

Title:
  Keystone Token Flush job does not complete in HA deployed environment

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Won't Fix
Status in OpenStack Identity (keystone) ocata series:
  Fix Released
Status in puppet-keystone:
  Fix Released
Status in tripleo:
  Fix Released
Status in keystone package in Ubuntu:
  Invalid
Status in keystone source package in Xenial:
  Fix Released
Status in keystone source package in Yakkety:
  Fix Released
Status in keystone source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * The Keystone token flush job can get into a state where it will
  never complete because the transaction size exceeds the mysql galara
  transaction size - wsrep_max_ws_size (1073741824).

  [Test Case]

  1. Authenticate many times
  2. Observe that keystone token flush job runs (should be a very long time 
depending on disk) >20 hours in my environment
  3. Observe errors in mysql.log indicating a transaction that is too large

  Actual results:
  Expired tokens are not actually flushed from the database without any errors 
in keystone.log.  Only errors appear in mysql.log.

  Expected results:
  Expired tokens to be removed from the database

  [Additional info:]

  It is likely that you can demonstrate this with less than 1 million
  tokens as the >1 million token table is larger than 13GiB and the max
  transaction size is 1GiB, my token bench-marking Browbeat job creates
  more than needed.

  Once the token flush job can not complete the token table will never
  decrease in size and eventually the cloud will run out of disk space.

  Furthermore the flush job will consume disk utilization resources.
  This was demonstrated on slow disks (Single 7.2K SATA disk).  On
  faster disks you will have more capacity to generate tokens, you can
  then generate the number of tokens to exceed the transaction size even
  faster.

  Log evidence:
  [root@overcloud-controller-0 log]# grep " Total expired" 
/var/log/keystone/keystone.log
  2016-12-08 01:33:40.530 21614 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1082434
  2016-12-09 09:31:25.301 14120 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1084241
  2016-12-11 01:35:39.082 4223 INFO keystone.token.persistence.backends.sql [-] 
Total expired tokens removed: 1086504
  2016-12-12 01:08:16.170 32575 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1087823
  2016-12-13 01:22:18.121 28669 INFO keystone.token.persistence.backends.sql 
[-] Total expired tokens removed: 1089202
  [root@overcloud-controller-0 log]# tail mysqld.log
  161208  1:33:41 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161208  1:33:41 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161209  9:31:26 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161209  9:31:26 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161211  1:35:39 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161211  1:35:40 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161212  1:08:16 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161212  1:08:17 [ERROR] WSREP: rbr write fail, data_len: 0, 2
  161213  1:22:18 [Warning] WSREP: transaction size limit (1073741824) 
exceeded: 1073774592
  161213  1:22:19 [ERROR] WSREP: rbr write fail, data_len: 0, 2

  Disk utilization issue graph is attached.  The entire job in that
  graph takes from the first spike is disk util(~5:18UTC) and culminates
  in about ~90 minutes of pegging the disk (between 1:09utc to 2:43utc).

  [Regression Potential] 
  * Not identified

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1649616/+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 1793347] Re: keystone upgrade fails q->r oslo.log requirement to low

[Morgan Fainberg]

This isn't something Keystone directly has control over, what is in our
requirements/g-r is what we ship with. Marking as invalid for keystone
server.

** Changed in: 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/1793347

Title:
  keystone upgrade fails q->r oslo.log requirement to low

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive rocky series:
  Fix Released
Status in OpenStack Identity (keystone):
  Invalid
Status in keystone package in Ubuntu:
  Fix Released
Status in keystone source package in Cosmic:
  Fix Released

Bug description:
  When upgrading from Keystone queens to rocky the requirements.txt for
  rocky says oslo.log >= 3.36.0 but versionutils.deprecated.ROCKY is not
  introduced until 3.37.0

  Should bump requirements.txt to atleast 3.37.0

  Error when running db sync:
  Traceback (most recent call last):
File "/bin/keystone-manage", line 6, in 
  from keystone.cmd.manage import main
File "/usr/lib/python2.7/site-packages/keystone/cmd/manage.py", line 19, in 

  from keystone.cmd import cli
File "/usr/lib/python2.7/site-packages/keystone/cmd/cli.py", line 29, in 

  from keystone.cmd import bootstrap
File "/usr/lib/python2.7/site-packages/keystone/cmd/bootstrap.py", line 17, 
in 
  from keystone.common import driver_hints
File "/usr/lib/python2.7/site-packages/keystone/common/driver_hints.py", 
line 18, in 
  from keystone import exception
File "/usr/lib/python2.7/site-packages/keystone/exception.py", line 20, in 

  import keystone.conf
File "/usr/lib/python2.7/site-packages/keystone/conf/__init__.py", line 27, 
in 
  from keystone.conf import default
File "/usr/lib/python2.7/site-packages/keystone/conf/default.py", line 60, 
in 
  deprecated_since=versionutils.deprecated.ROCKY,
  AttributeError: type object 'deprecated' has no attribute 'ROCKY'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1793347/+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 1541656] Re: OAuth Identity token gives Forbidden

[Morgan Fainberg]

Marking as incomplete for OSC, please re-visit if it is still an issue
(many things have changed across the board) and invalid for keystone.

** Changed in: keystone
   Status: Incomplete => Won't Fix

-- 
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/1541656

Title:
  OAuth Identity token gives Forbidden

Status in OpenStack Identity (keystone):
  Won't Fix
Status in python-openstackclient:
  New

Bug description:
  I have enabled OAuth1 in Keystone Kilo, then followed the flow described here:
  
https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-oauth1-ext.html#delegated-authentication-flow

  Created a consumer, created a request token, authorized the request
  token, exchanged it for an access token and finally obtained Identity
  token out of the access token, which looks like:

  HTTP/1.1 201 Created
  Date: Thu, 04 Feb 2016 00:20:13 GMT
  Server: Apache/2.4.10 (Linux/SUSE)
  Content-Length: 7982
  X-Subject-Token: 5bae545dc72d499bb3ec2792c9e53cbd
  Vary: X-Auth-Token
  x-openstack-request-id: req-241f91a2-8bc5-44a0-8676-8f521e074475
  Content-Type: application/json

  {"token": {"methods": ["oauth1"], "roles": [{"id":
  "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}],
  "expires_at": "2016-02-04T01:20:13.114596Z", "project": {"domain":
  {"id": "default", "name": "Default"}, "id": ..skipped catalog,
  etc. "OS-OAUTH1": {"access_token_id":
  "f718a55aeae24fa1930b726cbd41b378", "consumer_id":
  "979f33d9d2c54fd4ae9d5ed3c2c8f61b"}}}

  
  Then when I try to use the token for example to list servers:

  openstack --os-token 5bae545dc72d499bb3ec2792c9e53cbd --os-auth-url
  https://host:5000/v3 --os-identity-api-version 3 --os-cacert
  /etc/pki/trust/anchors/ca.pem --os-project-name Project1 server list

  I get a surprising error:

  Forbidden: You are not authorized to perform the requested action. (Disable 
debug mode to suppress these details.) (HTTP 403) (Request-ID: 
req-34f9098e-7f5d-45e6-95b6-6f4cac87159e)
   
  After some debugging I found out that my call gets rejected at:

  def token_authenticate(context, auth_payload, user_context, token_ref):
  try:

  # Do not allow tokens used for delegation to
  # create another token, or perform any changes of
  # state in Keystone. To do so is to invite elevation of
  # privilege attacks

  if token_ref.oauth_scoped or token_ref.trust_scoped:
  raise exception.Forbidden()

  What am I missing here? My token definitely is oauth_scoped and how am
  I supposed to use this Identity token?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1541656/+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 1235340] Re: Links always use public endpoint

[Morgan Fainberg]

Marking as wont fix. The solution has been discussed and is recommended
that the public_endpoint be unset.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1235340

Title:
  Links always use public endpoint

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  Link always uses public port.  It should use the port based on the
  request.

  e.g  if the call is   curl  https://localhost:35357/v3/users, I expect
  the link to have  https://localhost:35357/v3/users/  and not
  https://localhost:5000/v3/users.This defeats the whole purpose of
  having links for navigation.  Port 5000 may not even be accessible to
  the caller

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1235340/+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 1645263] Re: Unable to run stack.sh on fresh new Ubuntu Xenial 16.04 LTS, script fails with "No module named 'memcache' "

[Morgan Fainberg]

Marked as invalid. Not a lot we can do about python-memcached, but with
the py3-first testing i think we are beyond this as a bug.

** Changed in: keystone
   Status: Incomplete => 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/1645263

Title:
  Unable to run stack.sh on fresh new Ubuntu Xenial 16.04 LTS, script
  fails with "No module named 'memcache' "

Status in devstack:
  Opinion
Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Global Requirements:
  Opinion

Bug description:
  Unable to run stack.sh on fresh new Ubuntu Xenial 16.04 LTS, script
  fails with "No module named 'memcache' "

  Traceback:

  +lib/keystone:bootstrap_keystone:630   /usr/local/bin/keystone-manage 
bootstrap --bootstrap-username admin --bootstrap-password ubuntu 
--bootstrap-project-name admin --bootstrap-role-name admin 
--bootstrap-service-name keystone --bootstrap-region-id RegionOne 
--bootstrap-admin-url http://192.168.0.115/identity_admin 
--bootstrap-public-url http://192.168.0.115/identity --bootstrap-internal-url 
http://192.168.0.115/identity
  2016-11-28 11:51:39.723 15663 CRITICAL keystone [-] ImportError: No module 
named 'memcache'
  2016-11-28 11:51:39.723 15663 TRACE keystone Traceback (most recent call 
last):
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/bin/keystone-manage", line 10, in 
  2016-11-28 11:51:39.723 15663 TRACE keystone sys.exit(main())
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/cmd/manage.py", line 45, in main
  2016-11-28 11:51:39.723 15663 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/cmd/cli.py", line 1269, in main
  2016-11-28 11:51:39.723 15663 TRACE keystone CONF.command.cmd_class.main()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/cmd/cli.py", line 365, in main
  2016-11-28 11:51:39.723 15663 TRACE keystone klass = cls()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/cmd/cli.py", line 66, in __init__
  2016-11-28 11:51:39.723 15663 TRACE keystone self.load_backends()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/cmd/cli.py", line 129, in load_backends
  2016-11-28 11:51:39.723 15663 TRACE keystone drivers = 
backends.load_backends()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/server/backends.py", line 32, in load_backends
  2016-11-28 11:51:39.723 15663 TRACE keystone cache.configure_cache()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/opt/stack/keystone/keystone/common/cache/core.py", line 124, in 
configure_cache
  2016-11-28 11:51:39.723 15663 TRACE keystone 
cache.configure_cache_region(CONF, region)
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/oslo_cache/core.py", line 201, in 
configure_cache_region
  2016-11-28 11:51:39.723 15663 TRACE keystone '%s.' % 
conf.cache.config_prefix)
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/region.py", line 552, in 
configure_from_config
  2016-11-28 11:51:39.723 15663 TRACE keystone "%swrap" % prefix, None),
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/region.py", line 417, in 
configure
  2016-11-28 11:51:39.723 15663 TRACE keystone _config_prefix
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/api.py", line 81, in 
from_config_dict
  2016-11-28 11:51:39.723 15663 TRACE keystone for key in config_dict
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/backends/memcached.py", 
line 208, in __init__
  2016-11-28 11:51:39.723 15663 TRACE keystone super(MemcacheArgs, 
self).__init__(arguments)
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/backends/memcached.py", 
line 108, in __init__
  2016-11-28 11:51:39.723 15663 TRACE keystone self._imports()
  2016-11-28 11:51:39.723 15663 TRACE keystone   File 
"/usr/local/lib/python3.5/dist-packages/dogpile/cache/backends/memcached.py", 
line 287, in _imports
  2016-11-28 11:51:39.723 15663 TRACE keystone import memcache  # noqa
  2016-11-28 11:51:39.723 15663 TRACE keystone ImportError: No module named 
'memcache'
  2016-11-28 11:51:39.723 15663 TRACE keystone 

  local.conf

  [[local|localrc]]

  USE_PYTHON3=True
  PYTHON3_VERSION=3.5

  Python: 3.5.2

  Ubuntu version (lsb_release -a):
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04 LTS
  Release:  16.04
  Codename: xenial

[Yahoo-eng-team] [Bug 1630092] Re: Admin password reset should be exempt from password history validation

[Morgan Fainberg]

** Changed in: keystone/newton
   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/1630092

Title:
  Admin password reset should be exempt from password history validation

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Released

Bug description:
  In Newton, we added password history validation for all password
  changes. However, for administrative password resets, we shouldn't
  validate against the end-user's password history.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1630092/+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 1635306] Re: After newton deployment _member_ role is missing in keystone

[Morgan Fainberg]

** Changed in: keystone/newton
   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/1635306

Title:
  After newton deployment _member_ role is missing in keystone

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Released
Status in puppet-keystone:
  New
Status in tripleo:
  Invalid

Bug description:
  I did a full deployment using RDO Newton and at the end of deployment
  i see _member_ role is missing.

  [stack@topstrio1101 ~]$ openstack role list
  +--+-+
  | ID   | Name|
  +--+-+
  | 023e0f4fc56a47f7bada5fd512bab014 | swiftoperator   |
  | 48e4519e09b4469bbbf5c533830d3ad8 | heat_stack_user |
  | 52be634093e14ea7a1acdf3f5ec12066 | admin   |
  | a1f8e6636dc842d8a896a3e903298997 | ResellerAdmin   |
  +--+-+

  In Mitaka _member_ role has been created correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1635306/+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 1696111] Re: Keystone confuses users when creating a trust when there's a roles name conflict

[Morgan Fainberg]

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

** Changed in: python-keystoneclient
   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/1696111

Title:
  Keystone confuses users when creating a trust when there's a roles
  name conflict

Status in OpenStack Identity (keystone):
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in python-openstackclient:
  Fix Released

Bug description:
  Due to code [1] Keystone produces a confusing message when:

  * We're using python-openstackclient
  * We're creating a trust with a role name that exists in more that one domain.

  "role %s is not defined" suggests that there isn't a role like that.
  What actually happens, Keystone cannot decide which role is the user's
  choice.

  python-openstackclient automatically converts role ids to role names
  when sending a POST request, so specifying roles using an id doesn't
  help at all.


  [1]
  
https://github.com/openstack/keystone/blob/03319d1/keystone/trust/controllers.py#L90-L94

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1696111/+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 1717847] Re: Policy does not work for trusts

[Morgan Fainberg]

I'm going to mark this as opinion. It likely will get better with scope-
types and policy-in-code, but this bug in itself isn't relevant due to
how trusts were architected.

** Changed in: keystone
   Status: Confirmed => Opinion

-- 
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/1717847

Title:
  Policy does not work for trusts

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  see: http://lists.openstack.org/pipermail/openstack-
  dev/2017-September/122115.html

  In short, the trusts APIs handle their policy in code rather than from
  the policy file.

  This is rather confusing seeing as we have policies for trusts in the policy 
json file which do nothing:
  
https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142

  We should set better default policies, and change the code to respect
  the policy files rather than handle the policy checking based on
  hardcoded values.

  
  This change needs to be handled carefully (and made very obvious in release 
notes), because anyone using an older policy file once the change to respect 
the policy file is part of a release, will mean any authed user can list trusts 
because of the existing (and incorrect) default policy rules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1717847/+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 1704148] Re: OAUTH functional tests are broken on stable/ocata and stable/newton

[Morgan Fainberg]

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

** Changed in: keystone/ocata
   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/1704148

Title:
  OAUTH functional tests are broken on stable/ocata and stable/newton

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Released
Status in OpenStack Identity (keystone) ocata series:
  Fix Released

Bug description:
  Example failed job: http://logs.openstack.org/06/482606/1/check/gate-
  keystone-dsvm-functional-ubuntu-xenial/3bfe409/

  Example failure: http://paste.openstack.org/show/615277/

  Relevant logs: http://paste.openstack.org/show/615276/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1704148/+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 1703369] Re: get_identity_providers policy should be singular

[Morgan Fainberg]

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

** Changed in: keystone/newton
   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/1703369

Title:
  get_identity_providers policy should be singular

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Released
Status in OpenStack Identity (keystone) ocata series:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  identity:get_identity_providers should be
  identity:get_identity_provider (singular) since a GET is targeted on a
  single provider and the code is setup to check for
  identity:get_identity_provider (singular). See
  
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112

  found in master (pike)

  The ocata default policy.json also has this problem. Unless someone
  manually overrode policy to specify identity:get_identity_provider
  (singular), the result would be that the default rule was actually
  used for that check instead of identity:get_identity_providers. We
  could go back and fix the default policy.json for past releases, but
  the default actually has the same value as
  identity:get_identity_providers, and if nobody has complained it's
  probably safer to just leave it. It is, after all, just defaults there
  and anyone can override by specifying the correct value.

  But we must fix in pike to go along with the shift of policy into
  code. Policy defaults in code definitely need to match up with what
  the code actually checks. There should no longer be any reliance on
  the default rule.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1703369/+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 1767024] Re: pycadf fails on FIPS compliant system due to using md5

[Morgan Fainberg]

Not a bug in keystone. Something must be fixed in pycadf.

** Changed in: keystone
   Status: Incomplete => 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/1767024

Title:
  pycadf fails on FIPS compliant system due to using md5

Status in OpenStack Identity (keystone):
  Invalid
Status in pycadf:
  New

Bug description:
  I took a RHEL 7 system and enabled FIPS compliance (FIPS does not
  allow md5) and I see the following when keystone-manage is run. As a
  general rule, we should avoid using md5 if we can and move over to SHA
  wherever possible. The below also indicates that probably openstack
  auditing functional, which is internally dependent on pycadf might
  also be impacted.

File "/usr/bin/keystone-manage", line 6, in 
  from keystone.cmd.manage import main
File "/usr/lib/python2.7/site-packages/keystone/cmd/manage.py", line 19, in 

  from keystone.cmd import cli
File "/usr/lib/python2.7/site-packages/keystone/cmd/cli.py", line 29, in 

  from keystone.cmd import doctor
File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/__init__.py", 
line 14, in 
  from keystone.cmd.doctor import credential
File "/usr/lib/python2.7/site-packages/keystone/cmd/doctor/credential.py", 
line 16, in 
  from keystone.credential.providers import fernet as credential_fernet
File "/usr/lib/python2.7/site-packages/keystone/credential/__init__.py", 
line 15, in 
  from keystone.credential import controllers  # noqa
File "/usr/lib/python2.7/site-packages/keystone/credential/controllers.py", 
line 19, in 
  from keystone.common import controller
File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 
22, in 
  from keystone.common import authorization
File "/usr/lib/python2.7/site-packages/keystone/common/authorization.py", 
line 25, in 
  from keystone.models import token_model
File "/usr/lib/python2.7/site-packages/keystone/models/token_model.py", 
line 20, in 
  from keystone.federation import constants
File "/usr/lib/python2.7/site-packages/keystone/federation/__init__.py", 
line 15, in 
  from keystone.federation.core import *  # noqa
File "/usr/lib/python2.7/site-packages/keystone/federation/core.py", line 
24, in 
  from keystone import notifications
File "/usr/lib/python2.7/site-packages/keystone/notifications.py", line 29, 
in 
  from pycadf import eventfactory
File "/usr/lib/python2.7/site-packages/pycadf/eventfactory.py", line 16, in 

  from pycadf import event
File "/usr/lib/python2.7/site-packages/pycadf/event.py", line 20, in 

  from pycadf import identifier
File "/usr/lib/python2.7/site-packages/pycadf/identifier.py", line 33, in 

  md5_hash = hashlib.md5(CONF.audit.namespace.encode('utf-8'))
  ValueError: error:060800A3:digital envelope 
routines:EVP_DigestInit_ex:disabled for fip

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1767024/+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 1599546] Re: Make validation patterns configurable

[Morgan Fainberg]

Marking as invalid. Validation should not vary based upon options set in
configuration keystone-to-keystone. It makes it hard to know what to
expect when interacting with keystone.

** Changed in: keystone
   Status: In Progress => Opinion

-- 
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/1599546

Title:
  Make validation patterns configurable

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  Keystone now treats configuration like a module, making it easier to
  enforce import order without race conditions[0]. There are a few TODOs
  to make certain validation patterns configurable. With the way
  configuration was being handled before, we were unable to import
  values from configuration on import. Now that configuration is
  referenced like a module-level package, we can avoid those race
  conditions. By making validation configurable we'll allow
  operators/deployers to choose how strict they wish to validate
  specific types [1][2].


  [0] 
https://github.com/openstack/keystone/commit/d9c6b50a3ae514e640fa13a344e59fe3649ee0ef
  [1] 
https://github.com/openstack/keystone/blob/46b76a3d8e302f47daf04c739066f70b7438e0da/keystone/common/validation/parameter_types.py#L42-L43
  [2] 
https://github.com/openstack/keystone/blob/46b76a3d8e302f47daf04c739066f70b7438e0da/keystone/common/validation/parameter_types.py#L62-L64

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1599546/+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 1548580] Re: [FG-VD-16-010] Openstack Dashboard Brute Force Vulnerability Notification

[Morgan Fainberg]

I'm going to mark this as invalid. It is recommended to add a rate-
limiter in-front of the openstack services if needed. Ideally Keystone
could support such a bit of software, but it is largely out-of-scope
(can be supplied by the fronting webservers e.g. apache and
mod_ratelimit)

** Changed in: keystone
   Status: Triaged => 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/1548580

Title:
  [FG-VD-16-010] Openstack Dashboard Brute Force Vulnerability
  Notification

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Vulnerability Notification
  February 22, 2016
  Tracking Case #: FG-VD-16-010

  Dear Openstack,

  The following information pertains to information discovered by
  Fortinet's FortiGuard Labs. It has been determined that a
  vulnerability exists in Openstack Dashboard module.  To streamline the
  disclosure process, we have created a preliminary advisory which you
  can find below. This upcoming advisory is purely intended as a
  reference, and does not contain sensitive information such as proof of
  concept code.

  As a mature corporation involved in security research, we strive to
  responsibly disclose vulnerability information. We will not post an
  advisory until we determine it is appropriate to do so in co-
  ordination with the vendor unless a resolution cannot be reached. We
  will not disclose full proof of concept, only details relevant to the
  advisory.

  We look forward to working closely with you to resolve this issue, and
  kindly ask for your co-operation during this time. Please let us know
  if you have any further questions, and we will promptly respond to
  address any issues.

  If this message is not encrypted, it is because we could not find your
  key to do so. If you have one available for use, please notify us and
  we will ensure that this is used in future correspondence. We ask you
  use our public PGP key to encrypt and communicate any sensitive
  information with us. You may find the key on our FortiGuard center at:
  http://www.fortiguard.com/pgp_key.html.

  
  Type of Vulnerability & Repercussions:
Brute Force

  Affected Software:
Ubuntu 14.04.3 with latest repository installed
# apt-get install software-properties-common
# add-apt-repository cloud-archive:liberty


  Upcoming Advisory Reference:
http://www.fortiguard.com/advisory/UpcomingAdvisories.html

  Credits:
This vulnerability was discovered by Fortinet's FortiGuard Labs.

  
  Proof of Concept/How to Reproduce:
Run brute force attack against the Openstack dashboard using any user 
and password. Following is the login packet:


###
POST /horizon/auth/login/ HTTP/1.1
Host: 10.0.0.11
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 
Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.0.0.11/horizon/auth/login/
Cookie: csrftoken=plZbX8UMSn9jziJMfhHmC739KXYg8ANv; 
login_region="http://controller:5000/v2.0;
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 167


csrfmiddlewaretoken=plZbX8UMSn9jziJMfhHmC739KXYg8ANv_email=demo_password=admin123=http%3A%2F%2Fcontroller%3A5000%2Fv2.0=test=zxcvbnm
 

###
Notes: 
   1) Replace the above csrfmiddlewaretoken with a valid csrftoken in 
initial brute force attack. Valid csrftoken can be got from the response of 
http://10.0.0.11/horizon/auth/login/. 
   2) Openstack dashboard module doesn't have brute force attack detection 
and protection. 
  
   Additional Information:

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1548580/+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 1715080] Re: Update global requirements to handle encoding issues with python2-pyldap-2.4.35

[Morgan Fainberg]

This is just something to do, update global-requirments and it is
populated down. Updating global-requirements for a past release is hard
to do, it is suggested that you simply propose the changes and it will
be synchronized to keystone once it is approved.

** Changed in: keystone/pike
   Status: Confirmed => Won't Fix

** Changed in: keystone
   Status: Confirmed => Won't Fix

-- 
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/1715080

Title:
  Update global requirements to handle encoding issues with
  python2-pyldap-2.4.35

Status in OpenStack Identity (keystone):
  Won't Fix
Status in OpenStack Identity (keystone) pike series:
  Won't Fix

Bug description:
  With LDAP as identity backend and user/group name has non-ascii
  characters like "arc1Össk", when a role is assigned to such user it is
  failing in below stacktrace. UnicodeEncodeError issue is from
  python2-pyldap-2.4.35 installed. This issue was fixed in
  python2-pyldap-2.4.36 release with changes in
  https://github.com/pyldap/pyldap/pull/95.

  Currently stable/pike has global
  requirement(https://github.com/openstack/requirements/blob/stable/pike
  /global-requirements.txt#L195) of pyldap>=2.4.20 which needs to be
  changed to pyldap>=2.4.36.

  For more details on the issue, please refer to below links
  https://stackoverflow.com/questions/38616020/pyldap-dn-encoding-error
  https://github.com/pyldap/pyldap/issues/54

  
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi 
[req-8bc17bd4-e821-411d-b496-a75feca8448e 
91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e42 
38aa26ac274146778e655c6bcee3de68 - default default] 'ascii' codec can't encode 
character u'\xd6' in position 10: ordinal not in range(128): 
UnicodeEncodeError: 'ascii' codec can't encode character u'\xd6' in position 
10: ordinal not in range(128)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 228, in 
__call__
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi result = 
method(req, **params)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 93, in 
inner
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi self, f, 
check_function, request, None, *args, **kwargs)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 158, in 
protected_wrapper
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi 
check_function(self, request, prep_info, *args, **kwargs)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 
625, in _check_grant_protection
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi ref['user'] = 
self.identity_api.get_user(user_id)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/manager.py", l

  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py", 
line 634, in wrapper
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi return 
func(self, conn, *args, **kwargs)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py", 
line 764, in search_s
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi attrsonly)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 773, in search_s
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi return 
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 1180, in 
search_ext_s
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi return 
self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 1118, in 
_apply_method_s
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi return 
func(self,*args,**kwargs)
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 766, in 
search_ext_s
  2017-08-31 07:18:32.565 10756 ERROR keystone.common.wsgi msgid = 
self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
  2017-08-31 

[Yahoo-eng-team] [Bug 1680911] Re: Revoking an unscoped token does not revoke all tokens scoped from the unscoped token

[Morgan Fainberg]

Marking this as wont fix. This really is not something we can address in
a meaningful way at this time. It expands through a huge set of issues
across all of openstack and is not in line with the direction of the
project now.

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1680911

Title:
  Revoking an unscoped token does not revoke all tokens scoped from the
  unscoped token

Status in OpenStack Identity (keystone):
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  If you create an unscoped token (A) and you then use token A to
  create a project-scoped token (B) you now have
  token (A) [audit_id] = audit_id_a
  token (A) [audit_chain_id] = [audit_id_a]

  token (B) [audit_id] = audit_id_b
  token (B) [audit_chain_id] = [audit_id_a, audit_id_b]

  If you Revoke(token A) then token B should also be invalid.
  However, this is not the case currently as there are two reasons
  for this.
  There is a bug that doesn't correctly catch this in revoke_models
  because it accidently changes a list to a list in a tuple:
  
https://github.com/openstack/keystone/blob/master/keystone/models/revoke_model.py#L200-L201
  This needs to have the comma removed from
  not in (token_values['audit_chain_id'],) to not in 
(token_values['audit_chain_id'])

  The second and main reason is because this functionality is never exposed to 
the user
  and in the code it is never run here:
  
https://github.com/openstack/keystone/blob/master/keystone/token/provider.py#L255-L277
  because revoke_chain=False in the parameter is never set to True in a call 
anywhere in
  the code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1680911/+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 1687593] Re: Create OAUTH request token gives 401 error when request url is admin endpoint

[Morgan Fainberg]

Newton is not maintained. Marked as wont fix.

** Changed in: keystone/newton
   Status: In Progress => Won't Fix

** Changed in: keystone/ocata
   Status: In Progress => Won't Fix

-- 
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/1687593

Title:
  Create OAUTH request token gives 401 error when request url is admin
  endpoint

Status in OpenStack Identity (keystone):
  Fix Committed
Status in OpenStack Identity (keystone) newton series:
  Won't Fix
Status in OpenStack Identity (keystone) ocata series:
  Won't Fix
Status in python-keystoneclient:
  In Progress

Bug description:
  Create request token API returns 401 error when the request URL is
  admin endpoint.

  Error scenario:
  URL used to generate OAUTH signature and for POST request is Keystone admin 
endpoint
  http:///identity_admin/v3/OS-OAUTH1/request_token

  Working scenario:
  When the URL used to generate OAUTH signature is public endpoint, then the 
response is 201. 
  http:///identity/v3/OS-OAUTH1/request_token

  Endpoints in devstack for identity:
  ocata@ocata-VirtualBox:~/devstack$ openstack endpoint list | grep identity
  | 549f73e17b0e471e95176bb508561bb3 | RegionOne | keystone | identity  
| True| internal  | http://192.168.56.101/identity|
  | 739cda51666f4ab197241beac5c5c14c | RegionOne | keystone | identity  
| True| admin | http://192.168.56.101/identity_admin  |
  | a0eb39c0ecff46c3b61bc6184c42bc13 | RegionOne | keystone | identity  
| True| public| http://192.168.56.101/identity

  
  Steps to reproduce the problem:

  Run the python script in the below link (by changing the necessary 
credentials and IP address)
  https://pastebin.com/AqL9674n

  If #L38 is modified to public endpoint (http:///identity/v3/OS-OAUTH1/request_token), the status code is 201.

  Seems like Keystone code verifies the OAUTH signature using Public
  endpoint irrespective of the request URL.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1687593/+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 1797446] [NEW] Make AuthContextMiddleware more flask friendly

[Morgan Fainberg]

Public bug reported:

AuthContextMiddleware requires a lot of modification of the code for
auth_token middleware. The code should be updated to ensure that there
are no-web-ob specific bits that need to be carried in keystone's tree.
This likely requires splitting the "tokenless auth" (x509) into a
separate flask-aware middleware and making KeystoneMiddleware only
require overloading the "fetch_token" method for use within Keystone.

This is a wishlist bug to eliminate the last hard dependencies within
Keystone Server on Webob and being 100% flask native (externally loaded
middleware makes no difference).

** Affects: keystone
 Importance: Wishlist
 Status: Triaged

** Affects: keystonemiddleware
 Importance: Wishlist
 Status: Triaged

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Wishlist

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

** Changed in: keystonemiddleware
   Status: New => Triaged

** Changed in: keystonemiddleware
   Importance: Undecided => Wishlist

-- 
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/1797446

Title:
  Make AuthContextMiddleware more flask friendly

Status in OpenStack Identity (keystone):
  Triaged
Status in keystonemiddleware:
  Triaged

Bug description:
  AuthContextMiddleware requires a lot of modification of the code for
  auth_token middleware. The code should be updated to ensure that there
  are no-web-ob specific bits that need to be carried in keystone's
  tree. This likely requires splitting the "tokenless auth" (x509) into
  a separate flask-aware middleware and making KeystoneMiddleware only
  require overloading the "fetch_token" method for use within Keystone.

  This is a wishlist bug to eliminate the last hard dependencies within
  Keystone Server on Webob and being 100% flask native (externally
  loaded middleware makes no difference).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1797446/+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 1791111] Re: allow change password upon first use as user

[Morgan Fainberg]

Keystone does not allow "login" for locked passwords, which includes
ones marked for "change before first use". Horizon needs to implement a
"change password form" (or a user must use the /v3/users/password API
directly).

This is not something that can/will be fixed in keystone.

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

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

-- 
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/179

Title:
  allow change password upon first use as user

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  It's impossible to reset your password in user level if
  "change_password_upon_first_use" is set.

  keystone.conf:
  [security_compliance]
  change_password_upon_first_use = True

  For new users it's impossible to reset your password via keystone. You
  can only reset the password via an admin, which created the user in
  the first place. So now the change_password_upon_first_use is kinda
  useless.

  (test2@test) [root@controller1 ~]# openstack user password set
  The password is expired and needs to be changed for user: 
bd3cc251fe694b15be88c443aa752ec1. (HTTP 401) (Request-ID: 
req-cdc7ddaf-d2ec-49ac-9708-2693811eb819)

  Desired situation: User can reset it's own password on first use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/179/+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 1792868] Re: Use uuidutils instead of uuid.uuid4()

[Morgan Fainberg]

In line with my comment on the proposed change:

I am not a fan of wrapping basic functions in python with extra layers
for the sake of extra layers.

I also do not think the is_uuid_like is strict enough for what we do in
keystone. is_uuid_like would need to have a strict enforcement that no
dashes are allowed for many of our storage cases if we were to lean on
it.

---

With the way keystone is setup, if someone were to change the underlying
id generator, it is possible that you could break all of keystone due to
how we've structured our expectations of IDs when they are auto
generated.

I'm going to hold with a firm -1. Bordering on a -2.

Unless there is a real drive to see some level of consistency
specifically for a uuid generation and we (as keystone) have high levels
of assurances that the function will never change (Even by accident), I
don't foresee changing my stance on this.

This holds especially true with some of the upcoming changes where we
are going to no longer generate explicitly uuids but utilize a
combination hashing mechanism to provide better IDs (in the case of
users). For now, this change is not consistent with the design of
Keystone.


---

I am moving this to an opinion. It is not in line with the general
direction of Keystone, but I can be convinced (longer term) to change my
-1 depending on the overall direction of OpenStack projects (if there is
a real drive for consistency on resource id generation).


** Changed in: keystone
   Status: In Progress => Opinion

-- 
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/1792868

Title:
  Use uuidutils instead of uuid.uuid4()

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  oslo_utils.uuidutils has a wrapper for generating uuids.
  We should only use that function when generating
  uuids for consistency like 
here:https://storyboard.openstack.org/#!/story/1082248.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1792868/+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 1792913] Re: Keystone HTTP 500: AttributeError: type object 'GroupsResource' has no attribute '_get_domain_id_from_token'

[Morgan Fainberg]

*** This bug is a duplicate of bug 1793027 ***
https://bugs.launchpad.net/bugs/1793027

** This bug has been marked a duplicate of bug 1793027
   Flask doesn't normalize domains sanely in some cases

-- 
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/1792913

Title:
  Keystone HTTP 500: AttributeError: type object 'GroupsResource' has no
  attribute '_get_domain_id_from_token'

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  openstacksdk CI seems broken by keystone:
  http://logs.openstack.org/18/602618/1/check/openstacksdk-functional-
  devstack-tips/02b87a9/controller/logs/screen-
  keystone.txt.gz?level=WARNING#_Sep_16_15_37_40_090447

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1792913/+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 1793027] [NEW] Flask doesn't normalize domains sanely in some cases

[Morgan Fainberg]

Public bug reported:

Under webob, domain normalization (for creation of some resources)
resulted in a few possible options:

  * Domain ID present in ref -> no change to ref
  
  * Domain ID not present, domain scoped token ->
ref['domain_id'] = scope domain id

  * Domain ID not present, "admin" token -> raise ValidationError

  * Domain ID not present, project scoped token -> default domain
[Deprecated functionality]

Under flask, only the first scenario worked. Keystone, Tempest, and Heat
all only test for actual explicit domain id specified on creation
(groups notably). Shade/SDK tests a broader form and caught this
error[0][1] (reported by Monty Taylor)

[0] 
http://logs.openstack.org/33/599533/1/gate/shade-functional-devstack-tips/0a92f9f/testr_results.html.gz
[1] 
http://logs.openstack.org/33/599533/1/gate/shade-functional-devstack-tips/0a92f9f/controller/logs/screen-keystone.txt.gz?level=ERROR

** Affects: keystone
 Importance: Critical
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Critical

** Changed in: keystone
     Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystone
Milestone: None => stein-1

-- 
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/1793027

Title:
  Flask doesn't normalize domains sanely in some cases

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  Under webob, domain normalization (for creation of some resources)
  resulted in a few possible options:

* Domain ID present in ref -> no change to ref

* Domain ID not present, domain scoped token ->
  ref['domain_id'] = scope domain id

* Domain ID not present, "admin" token -> raise ValidationError

* Domain ID not present, project scoped token -> default domain
  [Deprecated functionality]

  Under flask, only the first scenario worked. Keystone, Tempest, and
  Heat all only test for actual explicit domain id specified on creation
  (groups notably). Shade/SDK tests a broader form and caught this
  error[0][1] (reported by Monty Taylor)

  [0] 
http://logs.openstack.org/33/599533/1/gate/shade-functional-devstack-tips/0a92f9f/testr_results.html.gz
  [1] 
http://logs.openstack.org/33/599533/1/gate/shade-functional-devstack-tips/0a92f9f/controller/logs/screen-keystone.txt.gz?level=ERROR

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1793027/+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 1792047] [NEW] keystone rbacenforcer not populating policy dict with view args

[Morgan Fainberg]

*** This bug is a security vulnerability ***

Public security bug reported:

The old @protected decorator pushed the view arguments into the
policy_dict for enforcement purposes[0]. This was missed in the new
RBACEnforcer.

[0]
https://github.com/openstack/keystone/blob/294ca38554bb229f66a772e7dba35a5b08a36b20/keystone/common/authorization.py#L152

** Affects: keystone
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Affects: keystone/rocky
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Affects: keystone/stein
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Changed in: keystone
   Importance: Undecided => High

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Also affects: keystone/rocky
   Importance: Undecided
   Status: New

** Also affects: keystone/stein
   Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
   Status: Triaged

** Changed in: keystone/rocky
   Status: New => Triaged

** Changed in: keystone/rocky
   Importance: Undecided => High

** Changed in: keystone/rocky
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1792047

Title:
  keystone rbacenforcer not populating policy dict with view args

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  In Progress
Status in OpenStack Identity (keystone) stein series:
  In Progress

Bug description:
  The old @protected decorator pushed the view arguments into the
  policy_dict for enforcement purposes[0]. This was missed in the new
  RBACEnforcer.

  [0]
  
https://github.com/openstack/keystone/blob/294ca38554bb229f66a772e7dba35a5b08a36b20/keystone/common/authorization.py#L152

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1792047/+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 1777671] [NEW] Incorrect use of translation _()

[Morgan Fainberg]

Public bug reported:

Keystone uses translated strings both in logging an exceptions. This is
incorrect.

All strings that are passed to logging should remain un-translated. The
solution is to duplicate the string and pass the untranslated (not
wrapped with `_()`) to the logger while passing the translated `_()`
wrapped string to the exception.

Relevant Discussion: http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-
oslo.2018-06-18.log.html#t2018-06-18T22:03:19

** Affects: keystone
 Importance: Medium
 Status: Triaged


** Tags: low-hanging-fruit office-hours

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
Milestone: None => rocky-3

-- 
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/1777671

Title:
  Incorrect use of translation _()

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Keystone uses translated strings both in logging an exceptions. This
  is incorrect.

  All strings that are passed to logging should remain un-translated.
  The solution is to duplicate the string and pass the untranslated (not
  wrapped with `_()`) to the logger while passing the translated `_()`
  wrapped string to the exception.

  Relevant Discussion: http://eavesdrop.openstack.org/irclogs
  /%23openstack-oslo/%23openstack-
  oslo.2018-06-18.log.html#t2018-06-18T22:03:19

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1777671/+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 1776506] [NEW] Keystone JSON HOME on / fails

[Morgan Fainberg]

Public bug reported:

With the move to the compat dispatching for Flask, Keystone's JSON HOME
on GET / is now failing. This results in a 500 error and an exception
that looks like:

2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi 
[req-591e2ecd-8088-4d2e-a5ae-c23a1624187d - - - - -] Extra data: line 1 column 
5 - line 5 column 22 (char 4 - 52): ValueError: Extra data: line 1 column 5 - 
line 5 column 22 (char 4 - 52)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi Traceback (most recent 
call last):
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 211, in 
__call__
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi result = method(req, 
**params)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/version/controllers.py", line 167, 
in get_versions
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi v3_json_home = 
request_v3_json_home('/v3')
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/version/controllers.py", line 46, in 
request_v3_json_home
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi v3_json_home = 
jsonutils.loads(v3_json_home_str)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/oslo_serialization/jsonutils.py", line 264, 
in loads
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi return 
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/json/__init__.py", line 338, in loads
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi return 
_default_decoder.decode(s)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/json/decoder.py", line 369, in decode
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi raise 
ValueError(errmsg("Extra data", s, end, len(s)))
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi ValueError: Extra data: 
line 1 column 5 - line 5 column 22 (char 4 - 52)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi

** Affects: keystone
 Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Changed in: keystone
   Importance: Undecided => High

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystone
Milestone: None => rocky-3

** Changed in: keystone
   Status: New => Triaged

-- 
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/1776506

Title:
  Keystone JSON HOME on / fails

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  With the move to the compat dispatching for Flask, Keystone's JSON
  HOME on GET / is now failing. This results in a 500 error and an
  exception that looks like:

  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi 
[req-591e2ecd-8088-4d2e-a5ae-c23a1624187d - - - - -] Extra data: line 1 column 
5 - line 5 column 22 (char 4 - 52): ValueError: Extra data: line 1 column 5 - 
line 5 column 22 (char 4 - 52)
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi Traceback (most recent 
call last):
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 211, in 
__call__
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi result = 
method(req, **params)
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/version/controllers.py", line 167, 
in get_versions
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi v3_json_home = 
request_v3_json_home('/v3')
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/version/controllers.py", line 46, in 
request_v3_json_home
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi v3_json_home = 
jsonutils.loads(v3_json_home_str)
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/oslo_serialization/jsonutils.py", line 264, 
in loads
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi return 
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/json/__init__.py", line 338, in loads
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi return 
_default_decoder.decode(s)
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi   File 
"/usr/lib64/python2.7/json/decoder.py", line 369, in decode
  2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi ra

[Yahoo-eng-team] [Bug 1776504] [NEW] flaskification

[Morgan Fainberg]

Public bug reported:

Moving keystone to Flask away from it's home-grown WSGI framework is a
long-term plan. The major reasons for this is to ensure we have an easy
way for folks start contributing.

This will include a number of improvements including:

* moving to flask-restful for API definitions

* all routable paths will be owned by the base prefix (e.g.
keystone.api.user will own everything under /user/)

* Paste Deploy removed

** Affects: keystone
 Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Changed in: keystone
   Status: New => In Progress

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystone
Milestone: None => ongoing

-- 
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/1776504

Title:
  flaskification

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  Moving keystone to Flask away from it's home-grown WSGI framework is a
  long-term plan. The major reasons for this is to ensure we have an
  easy way for folks start contributing.

  This will include a number of improvements including:

  * moving to flask-restful for API definitions

  * all routable paths will be owned by the base prefix (e.g.
  keystone.api.user will own everything under /user/)

  * Paste Deploy removed

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1776504/+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 1578466] Re: keystone token cache should offer encryption like the middleware cache does

[Morgan Fainberg]

This is something we should build into oslo.cache. I have moved the bug
to wont fix in keystone and added oslo.cache.

** Also affects: oslo.cache
   Importance: Undecided
   Status: New

** Changed in: keystone
   Status: Triaged => Won't Fix

** Summary changed:

- keystone token cache should offer encryption like the middleware cache does
+ cache should offer encryption in a similar manner to keystonemiddleware cache 
does

-- 
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/1578466

Title:
  cache should offer encryption in a similar manner to
  keystonemiddleware cache does

Status in OpenStack Identity (keystone):
  Won't Fix
Status in oslo.cache:
  New

Bug description:
  Keystone middleware's caching of tokens offers HMAC validation and
  encryption of the tokens in the cache. This is important because
  memcache has literally zero authentication or protection from any user
  on the system.  So this feature should be ported in from keystone
  middleware into keystone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1578466/+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 1578401] Re: tokens in memcache have no/improper expiration

[Morgan Fainberg]

This is not a bug. Dogpile.cache can set an actual memcache expiration,
however, we have simply been leaning on the LRU capabilities on
memcache. For keystone this would need to be changed in oslo.cache not
in Keystone.

I am marking this as opinion, it's not really a bug, it is how we have
implemented the cache. We can revisit this if there is a desire as an
RFE for oslo.cache.

** Changed in: keystone
   Status: Confirmed => Opinion

-- 
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/1578401

Title:
  tokens in memcache have no/improper expiration

Status in OpenStack Identity (keystone):
  Opinion

Bug description:
  tokens stored in memcache have no (improper) expiration data when set.

  Found on stable/mikata and stable/liberty using cachepool backend and
  the non-pooled backend.

  When you store in memcache you can optionally pass in a time at which
  the value is no good, a ttl. Keystone should be doing this for it's
  local token cache but it doesn't look like it is.

  Here is a dump of some slabs that have tokens in them, last field is
  expiration time:

  stats cachedump 11 10
  ITEM 8302fc81f2ffb552d5ba8d3e5f0e182ee285786a [724 b; 1460583765 s]
  ITEM 2ffe5d0821302a8501068a8411ce1749cea0645b [776 b; 1460583765 s]
  ITEM eb6e6f7e9118133a9a98944da874ac1b59c5675b [724 b; 1460583765 s]
  ITEM ee076b853dd5e5956366854abf6c49dbdf5ee4c2 [723 b; 1460583765 s]

  Lets see if these are really tokens:

  get 8302fc81f2ffb552d5ba8d3e5f0e182ee285786a
  VALUE 8302fc81f2ffb552d5ba8d3e5f0e182ee285786a 1 724
  cdogpile.cache.api
  CachedValue
  p0
  ((dp1
  S'access'
  p2
  (dp3
  S'token'
  p4
  (dp5
  S'issued_at'
  p6
  S'2016-05-04T21:20:27.00Z'
  p7
  sS'expires'
  p8
  S'2016-05-04T23:20:27.146911Z'
  p9
  sS'id'
  p10
  V

  Yep thats a Fernet token.

  Dumping older and older stuff, I can find cached tokens that are 24
  hours old in here, 22 hours past our valid token deadline.

  
  So lets compare that to some tokens that keystone_authtoken middleware is 
caching for control services:

  stats cachedump 21 100
  ITEM tokens/418b2c5a0e67d022b0578fbc4c96abf4a4509e94aca4ca1595167f8f01448957 
[8463 b; 1462397763 s]
  ITEM tokens/2b5a26e3bdf4dec0caae141353297f0316b55daf683b4bc0fcd1ab7bf4ba8f9b 
[8312 b; 1462397539 s]
  ITEM tokens/778329eb53545cbd664fa67e6429f48692679f428077b48baa4991f13cc1817c 
[8312 b; 1462397538 s]
  ITEM tokens/b80b06cf688c37f8688c368a983c2fd533c662b7b3063c6a2665c59def958cdd 
[8312 b; 1462397537 s]
  ITEM tokens/61cd52b0654641a21c62831f6e5be9f0328898d05026d6bb91c787d79cb8b460 
[8463 b; 1462397536 s]

  All have valid and different expiration times so it's respecting my
  settings.

  So what's that timestamp in the earlier list? Well it's 4/13/2016,
  3:42:45 PM GMT-6:00 DST. That happens to be the last time memcache
  restarted and so I assume it's just filler.

  What's the impact?

  I've not figured out if there is one yet for sure. I have a token
  valid time of 2 hours and I had set cache time to the same. I did try
  to dig out an old token but it would not validate so I don't think
  there's a security issue. I suspect the main issue is that my keystone
  memcache always runs completely 100% full. We max memcache at 20% of
  RAM on a box, and that's a lot (20% of 256G). I suspect with no valid
  expiration time memcache is lazily evicting old tokens when it runs
  out of ram rather than replacing expired ones and not allocating more
  RAM.

  [PROD] mfisch@east-keystone-001:~$ cat /proc/3937/status
  Name: memcached
  State:S (sleeping)
  Tgid: 3937
  Ngid: 3937
  Pid:  3937
  PPid: 1
  TracerPid:0
  Uid:  65534   65534   65534   65534
  Gid:  65534   65534   65534   65534
  FDSize:   1024
  Groups:   0
  VmPeak:   54500552 kB
  VmSize:  54500552 kB<-- that's a lot of twinkies

  I feel this merits deeper investigation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1578401/+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 1763824] Re: JSON schema validator.nullable doesn't work with ENUMs

[Morgan Fainberg]

This also impacts ocata.

** Also affects: keystone/ocata
   Importance: Undecided
   Status: New

** Changed in: keystone/ocata
   Status: New => Won't Fix

-- 
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/1763824

Title:
  JSON schema validator.nullable doesn't work with ENUMs

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) ocata series:
  Won't Fix
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  Fix Released

Bug description:
  JSON Schema validator.nullable only sets null in the types list. This
  works except when an enum is set (such as the case with boolean) [0].

  The fix is to make validator.nullable() smart enough to add to the
  ENUM if ENUM is set as well as type.

  [0]
  
https://github.com/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1763824/+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 1763824] [NEW] JSON schema validator.nullable doesn't work with ENUMs

[Morgan Fainberg]

Public bug reported:

JSON Schema validator.nullable only sets null in the types list. This
works except when an enum is set (such as the case with boolean) [0].

The fix is to make validator.nullable() smart enough to add to the ENUM
if ENUM is set as well as type.

[0]
https://github.com/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43

** Affects: keystone
 Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Affects: keystone/pike
 Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Affects: keystone/queens
 Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Affects: keystone/rocky
 Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
 Status: In Progress

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Also affects: keystone/rocky
   Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
   Status: Triaged

** Also affects: keystone/pike
   Importance: Undecided
   Status: New

** Also affects: keystone/queens
   Importance: Undecided
   Status: New

** Changed in: keystone/queens
   Status: New => Triaged

** Changed in: keystone/pike
   Status: New => Triaged

** Changed in: keystone/queens
   Importance: Undecided => Medium

** Changed in: keystone/pike
   Importance: Undecided => Medium

** Changed in: keystone/pike
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystone/queens
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1763824

Title:
  JSON schema validator.nullable doesn't work with ENUMs

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  In Progress

Bug description:
  JSON Schema validator.nullable only sets null in the types list. This
  works except when an enum is set (such as the case with boolean) [0].

  The fix is to make validator.nullable() smart enough to add to the
  ENUM if ENUM is set as well as type.

  [0]
  
https://github.com/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1763824/+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 1750415] Re: validation of app cred tokens is dependent on CONF.token.cache_on_issue

[Morgan Fainberg]

Based upon research and discussions in IRC, turns out we do not store
the application_credential_id in the token payload. This means that if
the token is not pre-populated in the cache, the test will fail.

This also means that if the token cache expires, subsequent uses of the
token with the application cred will also fail / have inconsistent or
inappropriate behavior.

This requires a fix to add a formatter that includes
application_credentials (likely more than one). The issue is identified
by looking at
https://github.com/openstack/keystone/blob/c80df22669ae457f8a64ddef7d31f685f9ad1e01/keystone/token/token_formatters.py
and seeing that application credential is not stored anywhere but the
auth methods are properly populated.

** Also affects: keystone/rocky
   Importance: Critical
 Assignee: Lance Bragstad (lbragstad)
   Status: In Progress

** Also affects: keystone/queens
   Importance: Undecided
   Status: New

** Changed in: keystone/queens
   Importance: Undecided => Critical

** Changed in: keystone/queens
   Status: New => Triaged

** Changed in: keystone/queens
 Assignee: (unassigned) => Lance Bragstad (lbragstad)

-- 
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/1750415

Title:
  validation of app cred tokens is dependent on
  CONF.token.cache_on_issue

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) queens series:
  Triaged
Status in OpenStack Identity (keystone) rocky series:
  In Progress

Bug description:
  Some information in tokens obtained with application credentials isn't
  available unless caching is enabled. I was able to recreate this using
  some of the tests in test_v3_trust.py and by setting
  CONF.token.cache_on_issue to False, which resulted in a 500 because a
  specific key in the token reference wasn't available [0].

  Without digging into a bunch, I think this is because the token is
  cached when it is created, meaning the process to rebuild the entire
  authorization context at validation time is short-circuited.

  [0] http://paste.openstack.org/show/677666/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750415/+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 1735250] Re: Password column limit (128 char) in the Password table exceeded when using passwords exceeding 2000 characters

[Morgan Fainberg]

This is an issue with the SQLAlchemy hybrid_property.expression use in
the user ref, where .expression is returning Password.password.

This appears to be an incorrect use of hybrid_property.expression.

The net result is that in some cases we store the un-hashed password (in
memory only) on the Password.password which is 128 character max. The
unhashed password is overwritten before persisting to the DB by the
logic in the .settr.

** Changed in: keystone
   Status: New => Confirmed

** Changed in: keystone
   Importance: Undecided => High

** Changed in: keystone
Milestone: None => queens-3

** Also affects: keystone/pike
   Importance: Undecided
   Status: New

** Also affects: keystone/queens
   Importance: High
   Status: Confirmed

** Changed in: keystone/pike
   Status: New => Confirmed

** Changed in: keystone/pike
   Importance: Undecided => High

-- 
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/1735250

Title:
  Password column limit (128 char) in the Password table exceeded when
  using passwords exceeding 2000 characters

Status in OpenStack Identity (keystone):
  Confirmed
Status in OpenStack Identity (keystone) pike series:
  Confirmed
Status in OpenStack Identity (keystone) queens series:
  Confirmed

Bug description:
  Type: Automation Test case
  Last Successful Run: Newton

  Test Release: Pike

  Test:
  'openstack --os-username 'keystoneuser005_ber' --os-password 'Li69nux*' 
--os-project-name admin --os-auth-url http://192.168.204.2:5000/v3 
--os-region-name RegionOne --os-user-domain-name Default 
--os-project-domain-name Default --os-identity-api-version 3 --os-interface 
internal user set --password 

[Yahoo-eng-team] [Bug 1708005] Re: 6 out 10 keystone.tests.unit.test_cert_setup.* unit test cases failed in stable/newton branch

[Morgan Fainberg]

** Project changed: keystoneauth => keystone

-- 
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/1708005

Title:
  6 out 10 keystone.tests.unit.test_cert_setup.* unit test cases failed
  in stable/newton branch

Status in OpenStack Identity (keystone):
  New

Bug description:
  The failure were caused by the formatting string for command openssl.
  Here is the diff to fix the issue.

  $ git diff keystone/common/openssl.py
  diff --git a/keystone/common/openssl.py b/keystone/common/openssl.py
  index c581e8d..4ea2410 100644
  --- a/keystone/common/openssl.py
  +++ b/keystone/common/openssl.py
  @@ -217,7 +217,7 @@ class BaseCertificateConfigure(object):
   self.exec_command(['openssl', 'ca', '-batch',
  '-out', '%(signing_cert)s',
  '-config', '%(ssl_config)s',
  -   '-days', '%(valid_days)dd',
  +   '-days', '%(valid_days)d',
  '-cert', '%(ca_cert)s',
  '-keyfile', '%(ca_private_key)s',
  '-infiles', '%(request_file)s'])
  $ uname -a
  Linux os-cs-g3w-31.dft.twosigma.com 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 
(2017-03-30) x86_64 GNU/Linux
  $ git branch
master
  * stable/newton
  $ git log  | head -4
  commit 05a129e54573b6cbda1ec095f4526f2b9ba90a90
  Author: Boris Bobrov 
  Date:   Tue Apr 25 14:20:36 2017 +

  {0}
  
keystone.tests.unit.test_cert_setup.CertSetupTestCase.test_create_pki_certs_twice_without_rebuild
  [0.670882s] ... FAILED

  Captured pythonlogging:
  ~~~
  Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend.
  Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend.
  Adding cache-proxy 'oslo_cache.testing.CacheIsolatingProxy' to backend.
  NeedRegenerationException
  no value, waiting for create lock
  value creation lock  acquired
  Calling creation function
  Released creation lock
  The admin_token_auth middleware presents a security risk and should be 
removed from the [pipeline:api_v3], [pipeline:admin_api], and 
[pipeline:public_api] sections of your paste ini file.
  The admin_token_auth middleware presents a security risk and should be 
removed from the [pipeline:api_v3], [pipeline:admin_api], and 
[pipeline:public_api] sections of your paste ini file.
  The admin_token_auth middleware presents a security risk and should be 
removed from the [pipeline:api_v3], [pipeline:admin_api], and 
[pipeline:public_api] sections of your paste ini file.
  The admin_token_auth middleware presents a security risk and should be 
removed from the [pipeline:api_v3], [pipeline:admin_api], and 
[pipeline:public_api] sections of your paste ini file.
  make_dirs 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0755 user=None group=None
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0755 user=None(None) group=None(None)
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/openssl.conf'
 mode=0640 user=None(None) group=None(None)
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/index.txt'
 mode=0640 user=None(None) group=None(None)
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/serial'
 mode=0640 user=None(None) group=None(None)
  make_dirs 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0750 user=None group=None
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0750 user=None(None) group=None(None)
  Running command - openssl genrsa -out 
/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/cakey.pem
 2048
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/cakey.pem'
 mode=0640 user=None(None) group=None(None)
  make_dirs 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0755 user=None group=None
  set_permissions: 
path='/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs' 
mode=0755 user=None(None) group=None(None)
  Running command - openssl req -new -x509 -extensions v3_ca -key 
/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/cakey.pem
 -out 
/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/ca.pem 
-days 3650 -config 
/home/tsstack/openstack/keystone/keystone/tests/unit/tmp/40309/ssl/certs/openssl.conf
 -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com
  

[Yahoo-eng-team] [Bug 1615084] Re: Keystone server should define "type" attribute as a MIME Media Type but accepts everything

[Morgan Fainberg]

Keystoneclient has nothing to say about what the server accepts. If
anything this is a keystone issue.

** Project changed: python-keystoneclient => keystone

-- 
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/1615084

Title:
  Keystone server should define "type" attribute as a MIME Media Type
  but accepts everything

Status in OpenStack Identity (keystone):
  New

Bug description:
  The bug was discovered while writing the policies functional tests
  [1]. Keystone server should define "type" attribute as a MIME Media
  Type [2] but accepts everything, for example, UUID is accepted in [1]
  while creating and updating a policy.

  [1] 
https://review.openstack.org/#/c/337836/2/keystoneclient/tests/functional/v3/test_policies.py
  [2] 
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/policies.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615084/+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 1615076] Re: Keystone server does not define "enabled" attribute for Region but mentions in v3 regions.py

[Morgan Fainberg]

** Project changed: python-keystoneclient => keystone

-- 
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/1615076

Title:
  Keystone server does  not define "enabled" attribute for Region but
  mentions in v3 regions.py

Status in OpenStack Identity (keystone):
  New

Bug description:
  The bug was discovered while writing the region functional tests [1].
  The create() and update() calls [2] in regions.py mention the
  "enabled" attribute, but the specs [3] don't mention it and the code
  [4] doesn't support it. We don't check for "enabled" in the region
  schema either [5].

  So, it's being stored as an extra attribute and it even works if one
  passes {'enabled': 'WHATEVER'}

  [1] https://review.openstack.org/#/c/339158/
  [2] 
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/regions.py
  [3] 
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#regions-v3-regions
  [4] 
https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/sql.py#L33-L49
  [5] 
https://github.com/openstack/keystone/blob/master/keystone/catalog/schema.py#L17-L43

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615076/+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 1588860] Re: keystone-manage bootstrap cannot recover admin account

[Morgan Fainberg]

Mitaka is EOL

** Changed in: keystone/mitaka
   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/1588860

Title:
  keystone-manage bootstrap cannot recover admin account

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) mitaka series:
  Fix Released

Bug description:
  The keystone-manage bootstrap command is intended to supersede the
  admin_token middleware. However, one of the common use cases for the
  admin_token middleware was to provide a recovery mechanism for cloud
  operators that had accidentally disabled themselves or lost their
  password.

  However, even after attempting to "re-bootstrap" an existing admin
  with a known password (effectively performing a password reset), the
  admin is still not able to authenticate. The same is true if the admin
  was disabled.

  This was originally reported in #openstack-ansible by odyssey4me:

  [Fri 09:29]  dolphm lbragstad is keystone-manage bootstrap meant 
to skip the bootstrap if there are already settings in place? what is the right 
way to fix up creds that are lost somehow for the keystone admin?
  [Fri 09:30]  odyssey4me: bootstrap should be idempotent, but i don't 
think it'll change an admin's password if you specify something different
  [Fri 09:31]  dolphm so the options are, I guess, to delete the 
admin account in the db or to use the auth_token middleware?

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1588860/+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 1579604] Re: project delete returns 501 NotImplemented with templated catalog

[Morgan Fainberg]

Mitaka is EOL

** Changed in: keystone/mitaka
   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/1579604

Title:
  project delete returns 501 NotImplemented with templated catalog

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) mitaka series:
  Fix Released

Bug description:
  Have upgraded to Mitaka and getting a 501 when deleting a project.
  This happens in both v2 and v3 api. The project actually deletes.

  Am using stable/mitaka branch and the sql backend


  
  $ keystone tenant-create --name deleteme

  +-+--+
  |   Property  |  Value   |
  +-+--+
  | description |  |
  |   enabled   |   True   |
  |  id | 5fafe2512fb3404ead999c30a23d0107 |
  | name| deleteme |
  +-+--+

  
  $ keystone tenant-delete 5fafe2512fb3404ead999c30a23d0107

  The action you have requested has not been implemented. (HTTP 501)
  (Request-ID: req-7ad5ee51-539f-4780-a39a-0f4e9ad092dc)

  
  $ keystone tenant-get 5fafe2512fb3404ead999c30a23d0107

  No tenant with a name or ID of '5fafe2512fb3404ead999c30a23d0107'
  exists.



  In logs:

  2016-05-09 12:06:40.265 16723 WARNING keystone.common.wsgi 
[req-7ad5ee51-539f-4780-a39a-0f4e9ad092dc c0645ff94b864d3d84c438d9855f9cea 
9427903ca1544f0795ba4117d55ed9b2 - default default] The action you have 
requested has not been implemented.
  2016-05-09 12:06:40.269 16723 INFO eventlet.wsgi.server 
[req-7ad5ee51-539f-4780-a39a-0f4e9ad092dc c0645ff94b864d3d84c438d9855f9cea 
9427903ca1544f0795ba4117d55ed9b2 - default default] 128.250.116.173 - - 
[09/May/2016 12:06:40] "DELETE /v2.0/tenants/5fafe2512fb3404ead999c30a23d0107 
HTTP/1.1" 501 354 0.223312

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1579604/+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 1621626] Re: Unauthenticated requests return information

[Morgan Fainberg]

Mitaka is EOL

** Changed in: keystone/mitaka
   Status: New => Won't Fix

** Changed in: keystone/mitaka
   Status: Won't Fix => Fix Released

** Changed in: keystone/mitaka
   Status: Fix Released => Won't Fix

-- 
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/1621626

Title:
  Unauthenticated requests return information

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) mitaka series:
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  
  I can get information back on an unauthenticated request.

   $ curl 
http://192.168.122.126:35357/v3/projects/8d34a533f85b423e8589061cde451edd/users/68ec7d9b6e464649b11d1340d5e05666/roles/ca314e7f7faf4f948bf6e7cf2077806e
   {"error": {"message": "Could not find role: 
ca314e7f7faf4f948bf6e7cf2077806e", "code": 404, "title": "Not Found"}}

  This should have returned 401 Unauthenticated, like this:

   $ curl http://192.168.122.126:35357/v3/projects
   {"error": {"message": "The request you have made requires authentication.", 
"code": 401, "title": "Unauthorized"}}

  To recreate, just start up devstack on stable/mitaka and do the above
  request.

  I tried this on master and it's fixed. Probably by
  https://review.openstack.org/#/c/339356/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1621626/+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 1629446] Re: federated login fails after user is removed from group

[Morgan Fainberg]

Mitaka is EOL

** Changed in: keystone/mitaka
   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/1629446

Title:
  federated login fails after user is removed from group

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) mitaka series:
  Fix Released
Status in OpenStack Identity (keystone) newton series:
  Fix Committed

Bug description:
  A user part of a group in auth0 tries to login in using the mapping
  below just fine

  [
  {
  "local": [
  {
  "user": {
  "name": "{1}::{0}"
  }
  },
  {
  "domain": {
  "id": "default"
  },
  "groups": "{1}"
  }
  ],
  "remote": [
  {
  "type": "HTTP_OIDC_CLAIM_EMAIL"
  },
  {
  "type": "HTTP_OIDC_CLAIM_GROUPS"
  }
  ]
  }
  ]

  
  Once the user is removed from the group in auth0 and tries to login :

  Expected Result:
  Failed to log on to horizon as federation user using OpenID Connect protocol 
and got 401 code:

  {"error": {"message": "The request you have made requires
  authentication.", "code": 401, "title": "Unauthorized"}}

  Actual Result:
  Got 500 instead of 401

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request.", "code": 500, "title": "Internal Server
  Error"}}

  error in keystone-all.logs:

  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
[req-f5f27f59-788b-494b-9719-bcdbb6b628c0 - - - - -] unexpected EOF while 
parsing (, line 0)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/common/wsgi.py",
 line 249, in __call__
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi result = 
method(context, **params)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
 line 329, in federated_idp_specific_sso_auth
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi res = 
self.federated_authentication(context, idp_id, protocol_id)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/controllers.py",
 line 302, in federated_authentication
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi return 
self.authenticate_for_token(context, auth=auth)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
 line 396, in authenticate_for_token
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
self.authenticate(context, auth_info, auth_context)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/controllers.py",
 line 520, in authenticate
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi auth_context)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 65, in authenticate
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
self.identity_api)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 141, in handle_unscoped_token
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi federation_api, 
identity_api)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/auth/plugins/mapped.py",
 line 194, in apply_mapping_filter
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
identity_provider, protocol, assertion)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/common/manager.py",
 line 124, in wrapped
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi __ret_val = 
__f(*args, **kwargs)
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi   File 
"/opt/openstack/current/keystone/local/lib/python2.7/site-packages/keystone/federation/core.py",
 line 98, in evaluate
  2016-09-30 19:32:25.549 23311 ERROR keystone.common.wsgi 
mapped_properties = rule_processor.process(assertion_data)
  

[Yahoo-eng-team] [Bug 1701541] Re: Keystone v3/roles has differnt response for HEAD and GET (again)

[Morgan Fainberg]

As per lance, this is being marked as wont fix. we can re-visit when/if
microversions or v4 is implemented.

** Changed in: keystone
   Status: New => Won't Fix

-- 
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/1701541

Title:
  Keystone v3/roles has differnt response for HEAD and GET (again)

Status in OpenStack Identity (keystone):
  Won't Fix
Status in tempest:
  In Progress

Bug description:
  The issue is very similar to the one already discussed at 
  https://bugs.launchpad.net/keystone/+bug/1334368 , 
http://lists.openstack.org/pipermail/openstack-dev/2014-July/039140.html .

  # curl -v -X HEAD  
http://172.17.1.18:5000/v3/roles/7acb026c29a24fb2a1d92a4e5291de24/implies/11b21cc37d7644c8bc955ff956b2d56e
 -H "Content-Type: application/json" -H "X-Auth-Token: 
gABZViMqU8rSuv7qlmcUlv1hYHegvN6EelqJPt-MTWBkIOewhSjNeiwZcksDUKm2JOfNtw78iAAmscx86N9UiekxkluvzRpatFyWooOkCATkqJFn4HgCFr_an9X7kmOhJTOguqGH6uCYz4K6ak1NfuEvtRShe3lDXyScL51JaZqtw8bCWzo"
  * About to connect() to 172.17.1.18 port 5000 (#0)
  *   Trying 172.17.1.18...
  * Connected to 172.17.1.18 (172.17.1.18) port 5000 (#0)
  > HEAD 
/v3/roles/7acb026c29a24fb2a1d92a4e5291de24/implies/11b21cc37d7644c8bc955ff956b2d56e
 HTTP/1.1
  > User-Agent: curl/7.29.0
  > Host: 172.17.1.18:5000
  > Accept: */*
  > Content-Type: application/json
  > X-Auth-Token: 
gABZViMqU8rSuv7qlmcUlv1hYHegvN6EelqJPt-MTWBkIOewhSjNeiwZcksDUKm2JOfNtw78iAAmscx86N9UiekxkluvzRpatFyWooOkCATkqJFn4HgCFr_an9X7kmOhJTOguqGH6uCYz4K6ak1NfuEvtRShe3lDXyScL51JaZqtw8bCWzo
  > 
  < HTTP/1.1 204 No Content
  < Date: Fri, 30 Jun 2017 10:09:30 GMT
  < Server: Apache
  < Vary: X-Auth-Token
  < x-openstack-request-id: req-e64410ae-5d4a-48f7-8508-615752877277
  < Content-Type: text/plain
  < 
  * Connection #0 to host 172.17.1.18 left intact

  # curl -v -X GET  
http://172.17.1.18:5000/v3/roles/7acb026c29a24fb2a1d92a4e5291de24/implies/11b21cc37d7644c8bc955ff956b2d56e
 -H "Content-Type: application/json" -H "X-Auth-Token: 
gABZViMqU8rSuv7qlmcUlv1hYHegvN6EelqJPt-MTWBkIOewhSjNeiwZcksDUKm2JOfNtw78iAAmscx86N9UiekxkluvzRpatFyWooOkCATkqJFn4HgCFr_an9X7kmOhJTOguqGH6uCYz4K6ak1NfuEvtRShe3lDXyScL51JaZqtw8bCWzo"
  * About to connect() to 172.17.1.18 port 5000 (#0)
  *   Trying 172.17.1.18...
  * Connected to 172.17.1.18 (172.17.1.18) port 5000 (#0)
  > GET 
/v3/roles/7acb026c29a24fb2a1d92a4e5291de24/implies/11b21cc37d7644c8bc955ff956b2d56e
 HTTP/1.1
  > User-Agent: curl/7.29.0
  > Host: 172.17.1.18:5000
  > Accept: */*
  > Content-Type: application/json
  > X-Auth-Token: 
gABZViMqU8rSuv7qlmcUlv1hYHegvN6EelqJPt-MTWBkIOewhSjNeiwZcksDUKm2JOfNtw78iAAmscx86N9UiekxkluvzRpatFyWooOkCATkqJFn4HgCFr_an9X7kmOhJTOguqGH6uCYz4K6ak1NfuEvtRShe3lDXyScL51JaZqtw8bCWzo
  > 
  < HTTP/1.1 200 OK
  < Date: Fri, 30 Jun 2017 10:09:38 GMT
  < Server: Apache
  < Content-Length: 507
  < Vary: X-Auth-Token,Accept-Encoding
  < x-openstack-request-id: req-cc320571-a59d-4ea2-b459-117053367c55
  < Content-Type: application/json
  < 
  * Connection #0 to host 172.17.1.18 left intact
  {"role_inference": {"implies": {"id": "11b21cc37d7644c8bc955ff956b2d56e", 
"links": {"self": 
"http://172.17.1.18:5000/v3/roles/11b21cc37d7644c8bc955ff956b2d56e"}, "name": 
"tempest-role-1212191884"}, "prior_role": {"id": 
"7acb026c29a24fb2a1d92a4e5291de24", "links": {"self": 
"http://172.17.1.18:5000/v3/roles/7acb026c29a24fb2a1d92a4e5291de24"}, "name": 
"tempest-role-500046640"}}, "links": {"self": 
"http://172.17.1.18:5000/v3/roles/7acb026c29a24fb2a1d92

  
  mod_wsgi based on the version and configuration (WSGIMapHEADToGET (requires 
mod_wsgi >= 4.3.0)) mod_wsgi might send GET instead of HEAD in order to avoid 
invalid responses being cached in case of an application bug.

  Unfortunately tempest expects the wrong behavior, is it also needs to
  be changed,

  
tempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_implied_roles_create_check_show_delete[id-c90c316c-d706-4728-bcba-eb1912081b69]
  
-

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File 
"/usr/lib/python2.7/site-packages/tempest/api/identity/admin/v3/test_roles.py", 
line 228, in test_implied_roles_create_check_show_delete
  prior_role_id, implies_role_id)
File 
"/usr/lib/python2.7/site-packages/tempest/lib/services/identity/v3/roles_client.py",
 line 233, in check_role_inference_rule
  self.expected_success(204, resp.status)
File 
"/usr/lib/python2.7/site-packages/tempest/lib/common/rest_client.py", line 252, 
in expected_success
  raise exceptions.InvalidHttpSuccessCode(details)
  tempest.lib.exceptions.InvalidHttpSuccessCode: The success code is 
different than the expected one
  Details: Unexpected http success status 

[Yahoo-eng-team] [Bug 1644862] Re: domain ldap tls_cacertfile "forgotten" in multidomain configuration

[Morgan Fainberg]

Mitaka is EOL

** Changed in: keystone/mitaka
   Status: New => Won't Fix

** Changed in: keystone/mitaka
   Status: Won't Fix => Fix Released

** Changed in: keystone/mitaka
   Status: Fix Released => Won't Fix

-- 
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/1644862

Title:
  domain ldap tls_cacertfile "forgotten" in multidomain configuration

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Identity (keystone) mitaka series:
  Won't Fix

Bug description:
  Environment:
  Centos 7 using the OpenStack Mitaka release

  RPMS from:
  http://mirror.centos.org/centos/7/cloud/$basearch/openstack-mitaka/

  openstack-keystone-9.2.0-1.el7.noarch

  —

  I have a multidomain configuration with multiple AD backends in
  keystone.

  For one of the AD configurations I've configured a custom
  tls_cacertfile as follows:

  «
  [identity]
  driver = ldap

  [assignment]
  driver = ldap

  [ldap]
  url  = ldap://dc1.domain1.ca ldap://dc1.domain1.ca
  use_tls  = true
  …
  »

  For the other:

  «
  [identity]
  driver = ldap

  [assignment]
  driver = ldap

  [ldap]
  url  = ldap://dc1.domain2.ca ldap://dc2.domain2.ca
  query_scope  = sub
  use_tls  = true
  tls_cacertfile   = /etc/keystone/domains/domain2-caroot.pem
  …
  »

  What I've observed is when logging in to domain2 I will get very
  inconsistent behaviour:

  * sometimes fails: "Unable to retrieve authorized projects."
  * sometimes fails: "An error occurred authenticating. Please try again later."
  * sometimes fails: "Unable to authenticate to any available projects."
  * sometimes fails: "Invalid credentials."
  * sometimes succeeds

  Example traceback from keystone log:
  «
  2016-11-25 09:54:06.699 27879 INFO keystone.common.wsgi 
[req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] POST 
http://os-controller.lab.netdirect.ca:5000/v3/auth/tokens
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi 
[req-c145506b-69fc-4fc2-9bad-76d77a79e3ca - - - - -] {'info': "TLS error 
-8179:Peer's Certificate issuer is not recognized.", 'desc': 'Connect error'}
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  …
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/ldappool/__init__.py", line 224, in 
_create_connector
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi raise 
BackendError(str(exc), backend=conn)
  2016-11-25 09:54:07.147 27879 ERROR keystone.common.wsgi BackendError: 
{'info': "TLS error -8179:Peer's Certificate issuer is not recognized.", 
'desc': 'Connect error'}
  »

  I've also tried putting a merged tls_cacertfile containing the system
  default ca roots and the domain2-specific ca root. That felt like it
  improved but did not fix the problem.

  The workaround is putting the merged cacertfile into BOTH domain
  configurations, which should not be necessary. After doing so I
  haven't had any trouble.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1644862/+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 1587777] Re: Mitaka: dashboard performance

[Morgan Fainberg]

I am marking this bug closed as the two patches in #17 have merged (inc.
the backport).

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

** Changed in: keystone
   Importance: Undecided => Medium

-- 
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/158

Title:
  Mitaka: dashboard performance

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Environment: Openstack Mitaka on top of Leap 42.1, 1 control node, 2
  compute nodes, 3-node-Ceph-cluster.

  Issue: Since switching to Mitaka, we're experiencing severe delays
  when accessing the dashboard - i.e. switching between "Compute -
  Overview" and "Compute - Instances" takes 15+ seconds, even after
  multiple invocations.

  Steps to reproduce:
  1. Install Openstack Mitaka, incl. dashboard & navigate through the dashboard.

  Expected result:
  Browsing through the dashboard with reasonable waiting times.

  Actual result:
  Refreshing the dashboard can take up to 30 secs, switching between views 
(e.g. volumes to instances) takes about 15 secs in average.

  Additional information:
  I've had a look at the requests, the Apache logs and our control node's stats 
and noticed that it's a single call that's taking all the time... I see no 
indications of any error, it seems that once WSGI is invoked, that call simply 
takes its time. Intermediate curl requests are logged, so I see it's doing its 
work. Looking at "vmstat" I can see that it's user space taking all the load 
(Apache / mod_wsgi drives its CPU to 100%, while other CPUs are idle - and no 
i/o wait, no system space etc.).

  ---cut here---
  control1:/var/log # top
  top - 10:51:35 up 8 days, 18:16,  2 users,  load average: 2,17, 1,65, 1,48
  Tasks: 383 total,   2 running, 381 sleeping,   0 stopped,   0 zombie
  %Cpu0  : 31,7 us,  2,9 sy,  0,0 ni, 65,0 id,  0,3 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu1  : 13,1 us,  0,7 sy,  0,0 ni, 86,2 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu2  : 17,2 us,  0,7 sy,  0,0 ni, 81,2 id,  1,0 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu3  : 69,4 us, 12,6 sy,  0,0 ni, 17,9 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu4  : 14,6 us,  1,0 sy,  0,0 ni, 84,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu5  : 16,9 us,  0,7 sy,  0,0 ni, 81,7 id,  0,7 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu6  : 17,3 us,  1,3 sy,  0,0 ni, 81,0 id,  0,3 wa,  0,0 hi,  0,0 si,  0,0 
st
  %Cpu7  : 21,2 us,  1,3 sy,  0,0 ni, 77,5 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 
st
  KiB Mem:  65943260 total, 62907676 used,  3035584 free, 1708 buffers
  KiB Swap:  2103292 total,0 used,  2103292 free. 53438560 cached Mem

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
   6776 wwwrun20   0  565212 184504  13352 S 100,3 0,280   0:07.83 
httpd-prefork
   1130 root  20   0  399456  35760  22508 S 5,980 0,054 818:13.17 X
   1558 sddm  20   0  922744 130440  72148 S 5,316 0,198 966:03.82 
sddm-greeter
  20999 nova  20   0  285888 116292   5696 S 2,658 0,176 164:27.08 
nova-conductor
  21030 nova  20   0  758752 182644  16512 S 2,658 0,277  58:20.40 nova-api
  18757 heat  20   0  273912  73740   4612 S 2,326 0,112  50:48.72 
heat-engine
  18759 heat  20   0  273912  73688   4612 S 2,326 0,112   4:27.54 
heat-engine
  20995 nova  20   0  286236 116644   5696 S 2,326 0,177 164:38.89 
nova-conductor
  21027 nova  20   0  756204 180752  16980 S 2,326 0,274  58:20.09 nova-api
  21029 nova  20   0  756536 180644  16496 S 2,326 0,274 139:46.29 nova-api
  21031 nova  20   0  756888 180920  16512 S 2,326 0,274  58:36.37 nova-api
  24771 glance20   0 2312152 139000  17360 S 2,326 0,211  24:47.83 
glance-api
  24772 glance20   0  631672 111248   4848 S 2,326 0,169  22:59.77 
glance-api
  28424 cinder20   0  720972 108536   4968 S 2,326 0,165  28:31.42 
cinder-api
  28758 neutron   20   0  317708 101812   4472 S 2,326 0,154 153:45.55 
neutron-server

  #

  control1:/var/log # vmstat 1
  procs ---memory-- ---swap-- -io -system-- 
--cpu-
   r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa 
st
   1  0  0 2253144   1708 5344047200 46044 11  1 88 
 0  0
   0  0  0 2255588   1708 5344047600 0   568 3063 7627 15  1 83 
 0  0
   1  0  0 2247596   1708 5344047600 0   144 3066 6803 14  2 83 
 0  0
   1  0  0 2156008   1708 5344047600 072 3474 7193 25  3 72 
 0  0
   2  0  0 2131968   1708 5344048400 0   652 3497 8565 28  2 70 
 0  0
   3  1  0 2134000   1708 5344051200 0 14340 3629 10644 25  2 
71  2  0
   2  0  0 2136956   1708 5344058000 012 3483 10620 25  2 
70  3  0
   9  1  0 2138164   1708 5344059600 0   248 3442 9980 27  1 72 
 0  0
   4 

[Yahoo-eng-team] [Bug 1681348] Re: keystone list project api returns empty if "?name=" is added as url parameter

[Morgan Fainberg]

Unfortunately, we cannot change the behavior without a microversion
uspport or something similar. ?name= will need to maintain returning an
empty list, as that is the contract. I am closing this as wont fix.

** Changed in: keystone
   Status: New => Won't Fix

-- 
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/1681348

Title:
  keystone list project api returns empty if "?name=" is added as url
  parameter

Status in OpenStack Identity (keystone):
  Won't Fix

Bug description:
  request: https://{{keystone_ip}}:5000/v3/projects?name=
  expect: returns all projects of current user.
  but: return empty.

  Other OpenStack components obey this convention properly, so keystone
  is inconsistent with them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1681348/+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 1669070] Re: Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200

[Morgan Fainberg]

This isn't a bug. IF the {role_id} at the end of the call is not passed,
we use the list action of:

/v3/domains/{domain_id}/groups/{group_id}/roles/ (regardless of head or
get action)

If a role_id is passed, you're calling a different API. This is not a
great design, but this is working as intended.

** Changed in: keystone
   Status: Confirmed => 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/1669070

Title:
  Checking whether group has role assignment on domain without
  specifying a role ID result in HTTP 200

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  It should've been either 400 or 404. Steps to reproduce.

  1. install a vanilla devstack
  2. use "openstack group list" to find a group ID. Any group will do. i.e.

  openstack group list
  +--+---+
  | ID   | Name  |
  +--+---+
  | 64e5dcd8dea0429ca22f97bcac4629bc | admins|
  | 9ff3c6f47a034223ad19bb6d0dd52bb6 | nonadmins |
  +--+---+

  3. get a token. i.e. "openstack token issue"
  4. call the check group assignment on domain API using curl without 
specifying the role ID and you can see an HTTP 200 is returned. i.e.

  curl -v --head -H 'X-Auth-Token: 
gABYtwwzxv9T3fxnHY3Js2ln2lTvoi1fukAYe0NSXgoV9S1qI808zQSYJyKb1AtTBy3MNUJFONBb7rpsIAu12zfRlZulfOgl7vvD_EM1DkMogpIRQvotJN1aYKMq8XqcgZ-NikolKCpUfas30GMQPFOoPpJdz0qjfIcniX0ihzVRTDqVcb0'
 
http://localhost/identity/v3/domains/default/groups/64e5dcd8dea0429ca22f97bcac4629bc/roles/
  *   Trying 127.0.0.1...
  * Connected to localhost (127.0.0.1) port 80 (#0)
  > HEAD 
/identity/v3/domains/default/groups/64e5dcd8dea0429ca22f97bcac4629bc/roles/ 
HTTP/1.1
  > Host: localhost
  > User-Agent: curl/7.47.0
  > Accept: */*
  > X-Auth-Token: 
gABYtwwzxv9T3fxnHY3Js2ln2lTvoi1fukAYe0NSXgoV9S1qI808zQSYJyKb1AtTBy3MNUJFONBb7rpsIAu12zfRlZulfOgl7vvD_EM1DkMogpIRQvotJN1aYKMq8XqcgZ-NikolKCpUfas30GMQPFOoPpJdz0qjfIcniX0ihzVRTDqVcb0
  >
  < HTTP/1.1 200 OK
  HTTP/1.1 200 OK
  < Date: Wed, 01 Mar 2017 18:06:01 GMT
  Date: Wed, 01 Mar 2017 18:06:01 GMT
  < Server: Apache/2.4.18 (Ubuntu)
  Server: Apache/2.4.18 (Ubuntu)
  < Vary: X-Auth-Token
  Vary: X-Auth-Token
  < x-openstack-request-id: req-9ea5a135-4128-4967-8552-d1c6a7b63c97
  x-openstack-request-id: req-9ea5a135-4128-4967-8552-d1c6a7b63c97
  < Content-Length: 158
  Content-Length: 158
  < Content-Type: application/json
  Content-Type: application/json

  <
  * Connection #0 to host localhost left intact

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1669070/+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 1576765] Re: Potential DOS: Keystone Extra Fields

[Morgan Fainberg]

** Changed in: keystone
   Status: Triaged => Won't Fix

-- 
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/1576765

Title:
  Potential DOS: Keystone Extra Fields

Status in OpenStack Identity (keystone):
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A user that has rights to update a resource in Keystone (project,
  user, domain, etc) can inject extra data (near unlimited amounts) with
  data that is only limited by the maximum request size. The extra
  fields cannot be deleted (ever) in the current design (the value of
  the field can be set to ~1byte minimum). An update excluding the field
  leaves the field data intact as is.

  This means that a bad actor can update a keystone resource and do one
  of the following to DOS Keystone cluster, database replication,
  database traffic, etc:

  1) Create endless numbers of fields with very little data, that will
  cause longer and longer json serialization/deserailization times due
  to the volume of elements.

  2) Create endless numbers of fields with large data sets, increasing
  the delta of what is stored in the RDBMS and putting extra load on the
  replication/etc processes for the shared data. This potentially could
  be used as a vector to run the DB server out of
  ram/cache/buffers/disk. This also causes the issue itemized above (1).

  3) With HMT, it is possible to duplicate (as a domain/user) the above
  listed items with more and more resources.

  Memcache/caching will offset some of these issues until the memcache
  server can no longer store the data from the keystone resource due to
  exceeding the slab size (1MB) which could cause excessive load on the
  memcached servers/caching servers.

  With caching enabled, it is possible to run the keystone processes out
  of memory/DOS due to the request_local cache in use to ensure that the
  resources are fetched from the backend a single time (using a msgpack
  of the data stored in memory) for a given HTTP request.

  --- PROPOSED FIX --
  * Issue a security bug fix that by default disables the ability to store data 
in the extra fields for *ALL* keystone resources
  * Migrate any/all fields that keystone supports to first class-attributes 
(columns) in the SQL backend[s].
  * 2-Cycle deprecation before removal of the support for "extra" field storage 
(toggled via config value) - in the P Cycle extra fields will no longer be 
supported. All non-standard data will need to be migrated to an external 
metadata storage.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1576765/+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 1680040] Re: Not all GET should have a correspondent HEAD, and vice-versa

[Morgan Fainberg]

HEAD calls should still be supported. It may not make sense for some
things, but it can be useful (someone can check content length, which
should be identical, or headers, or any number of things that aren't
what you'd expect).

Simply put, it costs us *nothing* to support it.

** Changed in: 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/1680040

Title:
  Not all GET should have a correspondent HEAD, and vice-versa

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Most of keystone implement GET and HEAD for the same operation.

  This is okay when you are retrieving an entity or checking its
  existence, for example:

  GET /users/
  HEAD /users/

  However, there are some cases where having GET is obvious, but HEAD
  does not make any sense:

  GET /role_assignments
  HEAD /role_assignments

  GET /users/{user_id}/groups
  HEAD /users/{user_id}/groups

  The role assignments and groups will only be returned in those API,
  there is nothing to be checked, you cannot even specify anything to be
  checked.

  And it happens on the other way around too:

  HEAD /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}
  GET /OS-EP-FILTER/projects/{project_id}/endpoints/{endpoint_id}

  The endpoint to project association is not an entity by itself,
  performing a GET on it will not return anything, it will just check
  its existence, as does the HEAD request.

  This should be fixed, there is no need to maintain APIs that are not
  useful.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1680040/+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 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing

[Morgan Fainberg]

** Changed in: keystone/ocata
   Status: New => Won't Fix

** Changed in: keystone/mitaka
   Status: New => Won't Fix

** Changed in: keystone/newton
   Status: New => Won't Fix

-- 
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/1668503

Title:
  sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) mitaka series:
  Won't Fix
Status in OpenStack Identity (keystone) newton series:
  Won't Fix
Status in OpenStack Identity (keystone) ocata series:
  Won't Fix
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Keystone uses sha512_crypt for password hashing. This is insufficient
  and provides limited protection (even with 10,000 rounds) against
  brute-forcing of the password hashes (especially with FPGAs and/or GPU
  processing).

  The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512
  instead of sha512_crypt.

  This bug is marked as public security as bug #1543048 has already
  highlighted this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1668503/+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 1668503] Re: sha512_crypt is insufficient, use pdkfd_sha512 for password hashing

[Morgan Fainberg]

** Changed in: keystone
   Importance: Critical => High

** Also affects: keystone/mitaka
   Importance: Undecided
   Status: New

** Also affects: keystone/pike
   Importance: High
 Assignee: Morgan Fainberg (mdrnstm)
   Status: In Progress

** Also affects: keystone/newton
   Importance: Undecided
   Status: New

** Also affects: keystone/ocata
   Importance: Undecided
   Status: New

** Description changed:

- Keystone uses sha512_crypt for password hashing. This is completely
- insufficient and provides limited protection (even with 10,000 rounds)
- against brute-forcing of the password hashes (especially with FPGAs
- and/or GPU processing).
+ Keystone uses sha512_crypt for password hashing. This is insufficient
+ and provides limited protection (even with 10,000 rounds) against brute-
+ forcing of the password hashes (especially with FPGAs and/or GPU
+ processing).
  
  The correct mechanism is to use bcrypt, scrypt, or pdkfd_sha512 instead
  of sha512_crypt.
  
  This bug is marked as public security as bug #1543048 has already
  highlighted this issue.

-- 
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/1668503

Title:
  sha512_crypt is insufficient, use pdkfd_sha512 for password hashing

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) mitaka series:
  New
Status in OpenStack Identity (keystone) newton series:
  New
Status in OpenStack Identity (keystone) ocata series:
  New
Status in OpenStack Identity (keystone) pike series:
  In Progress
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Keystone uses sha512_crypt for password hashing. This is insufficient
  and provides limited protection (even with 10,000 rounds) against
  brute-forcing of the password hashes (especially with FPGAs and/or GPU
  processing).

  The correct mechanism is to use bcrypt, scrypt, or pdkfd_sha512
  instead of sha512_crypt.

  This bug is marked as public security as bug #1543048 has already
  highlighted this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1668503/+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 1668503] [NEW] sha512_crypt is insufficient, use pdkfd_sha512 for password hashing

[Morgan Fainberg]

*** This bug is a security vulnerability ***

Public security bug reported:

Keystone uses sha512_crypt for password hashing. This is completely
insufficient and provides limited protection (even with 10,000 rounds)
against brute-forcing of the password hashes (especially with FPGAs
and/or GPU processing).

The correct mechanism is to use bcrypt, scrypt, or pdkfd_sha512 instead
of sha512_crypt.

This bug is marked as public security as bug #1543048 has already
highlighted this issue.

** Affects: keystone
 Importance: Critical
 Assignee: Morgan Fainberg (mdrnstm)
 Status: Triaged

** Affects: ossa
 Importance: Undecided
 Status: Incomplete


** Tags: security

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

** Changed in: ossa
   Status: New => Incomplete

-- 
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/1668503

Title:
  sha512_crypt is insufficient, use pdkfd_sha512 for password hashing

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Keystone uses sha512_crypt for password hashing. This is completely
  insufficient and provides limited protection (even with 10,000 rounds)
  against brute-forcing of the password hashes (especially with FPGAs
  and/or GPU processing).

  The correct mechanism is to use bcrypt, scrypt, or pdkfd_sha512
  instead of sha512_crypt.

  This bug is marked as public security as bug #1543048 has already
  highlighted this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1668503/+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 1659051] Re: Use CORS set_defaults

[Morgan Fainberg]

Keystone does not call .set_latent anywhere. This is an issue with
oslo.middleware possibly.

** Changed in: 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/1659051

Title:
  Use CORS set_defaults

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  During test runs there are a lot of warnings for  DeprecationWarning:
  Method 'CORS.set_latent()' has moved to 'method.set_defaults()

  We should ensure keystone is using set_defaults instead of latent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1659051/+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 1659053] [NEW] use uuids with pycadf

[Morgan Fainberg]

Public bug reported:

pycadf warnings are plentiful in keystone tests: UserWarning: Invalid uuid. To 
ensure interoperability, identifiersshould be a valid uuid.
  warnings.warn('Invalid uuid. To ensure interoperability, identifiers'


Be sure keystone is providing uuids appropriately.

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
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/1659053

Title:
  use uuids with pycadf

Status in OpenStack Identity (keystone):
  New

Bug description:
  pycadf warnings are plentiful in keystone tests: UserWarning: Invalid uuid. 
To ensure interoperability, identifiersshould be a valid uuid.
warnings.warn('Invalid uuid. To ensure interoperability, identifiers'

  
  Be sure keystone is providing uuids appropriately.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1659053/+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 1659051] [NEW] Use CORS set_defaults

[Morgan Fainberg]

Public bug reported:

During test runs there are a lot of warnings for  DeprecationWarning:
Method 'CORS.set_latent()' has moved to 'method.set_defaults()

We should ensure keystone is using set_defaults instead of latent.

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
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/1659051

Title:
  Use CORS set_defaults

Status in OpenStack Identity (keystone):
  New

Bug description:
  During test runs there are a lot of warnings for  DeprecationWarning:
  Method 'CORS.set_latent()' has moved to 'method.set_defaults()

  We should ensure keystone is using set_defaults instead of latent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1659051/+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 1491926] Re: Remove padding from Fernet tokens

[Morgan Fainberg]

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

-- 
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/1491926

Title:
  Remove padding from Fernet tokens

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Won't Fix

Bug description:
  In bug 1433372, we determined that we should percent encode Fernet
  tokens, because the padding characters (=) aren't considered URL safe
  by some RFCs.

  We also fail some tempest tests because clients sometimes decode or
  encode responses [0]. We should just remove the padding, that way
  clients don't have to worry about it. When we go to validate a token,
  we can determine what the padding is based on the length of the token:

  missing_padding = 4 - len(token) % 4
  if missing_padding:
  token += b'=' * missing_padding

  
  A patch can be proposed to master, stable/liberty, and stable/kilo to ensure 
that Fernet tokens can be validated regardless of padding. This is important to 
consider when upgrading from Kilo to Liberty or Kilo to Mitaka.

  [0] http://cdn.pasteraw.com/es3j52dpfgem4nom62e7vktk7g5u2j1

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1491926/+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 1488208] Re: Revoking a role assignment revokes unscoped tokens too

[Morgan Fainberg]

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

-- 
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/1488208

Title:
  Revoking a role assignment revokes unscoped tokens too

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Won't Fix

Bug description:
  When you delete a role assignment using a user+role+project pairing,
  unscoped tokens between the user+project are unnecessarily revoked as
  well. In fact, two events are created for each role assignment
  deletion (one that is scoped correctly and one that is scoped too
  broadly).

  The test failure in https://review.openstack.org/#/c/216236/
  illustrates this issue:

http://logs.openstack.org/36/216236/1/check/gate-keystone-
  python27/3f44af1/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1488208/+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 1490804] Re: [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546)

[Morgan Fainberg]

** Changed in: keystone/kilo
   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/1490804

Title:
  [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546)

Status in django-openstack-auth:
  Invalid
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in keystonemiddleware:
  Fix Released
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released
Status in python-keystoneclient:
  Won't Fix

Bug description:
  A keystone token which has been revoked can still be used by manipulating 
particular byte fields within the token.
  When a Keystone token is revoked it is added to the revoked list which stores 
the exact token value. Any API will look at the token to see whether or not it 
should accept a token. By changing a single byte within the token, the 
revocation can be bypassed.  see the testing script [1].

  It is suggested that the revocation should be changed to only check
  the token's inner ID.

  [1] http://paste.openstack.org/show/436516/

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+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 1484237] Re: token revocations not always respected when using fernet tokens

[Morgan Fainberg]

Kilo is EOL

** Changed in: keystone/kilo
   Status: In Progress => Won't Fix

-- 
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/1484237

Title:
  token revocations not always respected when using fernet tokens

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1484237/+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 1541621] Re: Invalid fernet X-Subject-Token token should result in 404 instead of 401

[Morgan Fainberg]

** Changed in: keystone/liberty
   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/1541621

Title:
  Invalid fernet X-Subject-Token token should result in 404 instead of
  401

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  When a scoped fernet token is no longer valid (i.e. all the roles had
  been removed from the scope), token validation should result in 404
  instead of 401. According to Keystone V3 API spec, 401 is returned
  only if X-Auth-Token is invalid [0]. Invalid X-Subject-Token should
  yield 404. Furthermore, auth_token middleware only treat 404 as
  invalid subject token and cache it accordingly [1]. Improper 401 will
  cause unnecessary churn as middleware will repeatedly attempt to  re-
  authenticate the service user.

  
  To reproduce the problem:

  1. get a project scoped token
  2. remove all the roles assigned to the user for that project
  3. attempt to validate that project-scoped token will result in 401

  [0] 
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#401-unauthorized
  [1] 
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_identity.py#L215

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1541621/+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 1527759] Re: Default domain no longer lets keystone tenant-list work

[Morgan Fainberg]

** Changed in: keystone/liberty
   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/1527759

Title:
  Default domain no longer lets keystone tenant-list work

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Won't Fix
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  We recently upgraded from kilo.0 to kilo.2 in our dev environment and
  noticed that keystone tenant-list is always failing for the admin
  user.

  Our config is as follows default domain is tied to read-only ldap
  (AD), a heat domain is created to use for trusts to handle the created
  heatstack users/passwords. Under kilo.0 everything was happy. Under
  kilo0.2 we get the following error:

  keystone tenant-list
  The request you have made requires authentication. (HTTP 401) (Request-ID: 
req-d30289f0-778d-4577-8150-7ddd5438ad9c)

  The main error message is:
  2015-12-16 17:07:36.493 20386 WARNING keystone.common.wsgi [-] Authorization 
failed. Non-default domain is not supported (Disable debug mode to suppress 
these details.) (Disable debug mode to suppress these details.) from 
10.224.48.132

  Looking at the differences between kilo.0 and kilo.2  it seems like:
  
https://github.com/openstack/keystone/commit/9dfad21201251364c6d205e8e79813bfe78e6107
  is the most likely culprit for this regression. However, I have not
  yet been able to test if reverting that change fixes the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1527759/+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 1526976] Re: Any operation without token fails with internal server error for fernet token

[Morgan Fainberg]

** Changed in: keystone/liberty
   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/1526976

Title:
  Any operation without token fails with internal server error for
  fernet token

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  This bug is only for fernet token.  Configure keystone to use fernet
  token. Call any operation without passing a X-Auth-Token. It reports
  500 error. It should throw 401

  e.g curl -X DELEETE $OS_AUTH_URL/v3/projects/https://bugs.launchpad.net/keystone/+bug/1526976/+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 1497461] Re: Fernet tokens fail for some users with LDAP identity backend

[Morgan Fainberg]

** Changed in: keystone/liberty
   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/1497461

Title:
  Fernet tokens fail for some users with LDAP identity backend

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in OpenStack Identity (keystone) liberty series:
  Fix Released

Bug description:
  The following bug fixed most situations where when using Fernet + LDAP 
identify backend.
  https://bugs.launchpad.net/keystone/+bug/1459382

  However, some users have trouble, resulting in a UserNotFound exception in 
the logs with a UUID.  Here's the error:
  2015-09-18 20:04:47.313 12979 WARNING keystone.common.wsgi [-] Could not find 
user: 457269632042726f776e203732363230

  So the issue is this.  The user DN query + filter will return my user as:
 CN=Eric Brown 
72620,OU=PAO_Users,OU=PaloAlto_California_USA,OU=NALA,OU=SITES,OU=Engineering,DC=vmware,DC=com

  Therefore, I have to use CN as the user id attribute.  My user id
  would therefore be "Eric Brown 72620".  The fernet token_formatters.py
  attempts to convert this user id into a UUID.  And in my case that is
  successful.  It results in UUID of 457269632042726f776e203732363230.
  Of course, a user id of 457269632042726f776e203732363230 doesn't exist
  in LDAP, so as a result I get a UserNotFound.  So I don't understand
  why the convert_uuid_bytes_to_hex is ever used in the case of LDAP
  backend.

  For other users, the token_formatters.convert_uuid_bytes_to_hex()
  raises a ValueError and everything works.  Here's an example that
  illustrates the behavior

  >>> import uuid
  >>> uuid_obj = uuid.UUID(bytes='Eric Brown 72620')
  >>> uuid_obj.hex
  '457269632042726f776e203732363230'

  >>> import uuid
  >>> uuid_obj = uuid.UUID(bytes='Your Mama')
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python2.7/uuid.py", line 144, in __init__
  raise ValueError('bytes is not a 16-char string')
  ValueError: bytes is not a 16-char string



  Here's the complete traceback (after adding some additional debug):

  2015-09-18 20:04:47.312 12979 WARNING keystone.common.wsgi [-] EWB Traceback 
(most recent call last):
File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 449, 
in __call__
  response = self.process_request(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 
238, in process_request
  auth_context = self._build_auth_context(request)
File "/usr/lib/python2.7/dist-packages/keystone/middleware/core.py", line 
218, in _build_auth_context
  token_data=self.token_provider_api.validate_token(token_id))
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 
198, in validate_token
  token = self._validate_token(unique_id)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, 
in decorate
  should_cache_fn)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, 
in get_or_create
  async_creator) as value:
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, 
in __enter__
  return self._enter()
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, 
in _enter
  generated = self._enter_create(createdtime)
File "/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149, 
in _enter_create
  created = self.creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 612, 
in gen_value
  created_value = creator()
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1009, 
in creator
  return fn(*arg, **kw)
File "/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 
261, in _validate_token
  return self.driver.validate_v3_token(token_id)
File 
"/usr/lib/python2.7/dist-packages/keystone/token/providers/fernet/core.py", 
line 258, in validate_v3_token
  audit_info=audit_ids)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", 
line 441, in get_token_data
  self._populate_user(token_data, user_id, trust)
File "/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", 
line 275, in _populate_user
  user_ref = self.identity_api.get_user(user_id)
File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 
342, in wrapper
  return f(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/keystone/identity/core.py", line 
353, in wrapper
  return f(self, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1013, 
in decorate
  should_cache_fn)
File "/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 640, 
in get_or_create

[Yahoo-eng-team] [Bug 1555187] Re: keystone fails to start in kilo due to pysaml2 4.0.4 release

[Morgan Fainberg]

** Changed in: keystone/kilo
   Status: In Progress => 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/1555187

Title:
  keystone fails to start in kilo due to pysaml2 4.0.4 release

Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Identity (keystone) kilo series:
  Fix Released

Bug description:
  http://logs.openstack.org/66/278466/8/check/gate-heat-dsvm-functional-
  orig-mysql-
  lbaasv1/26b4f7d/logs/apache/keystone.txt.gz#_2016-03-09_14_12_14_814037

  2016-03-09 14:12:14.807391 mod_wsgi (pid=27348): Exception occurred 
processing WSGI script '/var/www/keystone/main'.
  2016-03-09 14:12:14.807440 Traceback (most recent call last):
  2016-03-09 14:12:14.807474   File "/var/www/keystone/main", line 25, in 

  2016-03-09 14:12:14.807536 application = 
wsgi_server.initialize_application(name)
  2016-03-09 14:12:14.807552   File 
"/opt/stack/new/keystone/keystone/server/wsgi.py", line 51, in 
initialize_application
  2016-03-09 14:12:14.807574 startup_application_fn=loadapp)
  2016-03-09 14:12:14.807586   File 
"/opt/stack/new/keystone/keystone/server/common.py", line 43, in setup_backends
  2016-03-09 14:12:14.807603 res = startup_application_fn()
  2016-03-09 14:12:14.807615   File 
"/opt/stack/new/keystone/keystone/server/wsgi.py", line 48, in loadapp
  2016-03-09 14:12:14.807632 'config:%s' % config.find_paste_config(), name)
  2016-03-09 14:12:14.807643   File 
"/opt/stack/new/keystone/keystone/service.py", line 45, in loadapp
  2016-03-09 14:12:14.807740 controllers.latest_app = deploy.loadapp(conf, 
name=name)
  2016-03-09 14:12:14.807757   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
  2016-03-09 14:12:14.808057 return loadobj(APP, uri, name=name, **kw)
  2016-03-09 14:12:14.808096   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
  2016-03-09 14:12:14.808122 return context.create()
  2016-03-09 14:12:14.808135   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in 
create
  2016-03-09 14:12:14.808152 return self.object_type.invoke(self)
  2016-03-09 14:12:14.808162   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in 
invoke
  2016-03-09 14:12:14.808176 **context.local_conf)
  2016-03-09 14:12:14.808187   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in 
fix_call
  2016-03-09 14:12:14.808277 val = callable(*args, **kw)
  2016-03-09 14:12:14.808300   File 
"/usr/local/lib/python2.7/dist-packages/paste/urlmap.py", line 31, in 
urlmap_factory
  2016-03-09 14:12:14.808447 app = loader.get_app(app_name, 
global_conf=global_conf)
  2016-03-09 14:12:14.808465   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
  2016-03-09 14:12:14.808485 name=name, global_conf=global_conf).create()
  2016-03-09 14:12:14.808494   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
  2016-03-09 14:12:14.808508 APP, name=name, global_conf=global_conf)
  2016-03-09 14:12:14.808516   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
  2016-03-09 14:12:14.808529 global_additions=global_additions)
  2016-03-09 14:12:14.808538   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 562, in 
_pipeline_app_context
  2016-03-09 14:12:14.808552 for name in pipeline[:-1]]
  2016-03-09 14:12:14.808560   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 458, in 
get_context
  2016-03-09 14:12:14.808573 section)
  2016-03-09 14:12:14.808582   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 517, in 
_context_from_explicit
  2016-03-09 14:12:14.808595 value = import_string(found_expr)
  2016-03-09 14:12:14.808606   File 
"/usr/local/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 22, in 
import_string
  2016-03-09 14:12:14.808621 return pkg_resources.EntryPoint.parse("x=" + 
s).load(False)
  2016-03-09 14:12:14.808640   File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2202, 
in load
  2016-03-09 14:12:14.810590 return self.resolve()
  2016-03-09 14:12:14.810636   File 
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2208, 
in resolve
  2016-03-09 14:12:14.810691 module = __import__(self.module_name, 
fromlist=['__name__'], level=0)
  2016-03-09 14:12:14.810711   File 
"/opt/stack/new/keystone/keystone/contrib/federation/routers.py", line 17, in 

  2016-03-09 14:12:14.810904 from keystone.contrib.federation import 
controllers
  2016-03-09 14:12:14.810929   File 

[Yahoo-eng-team] [Bug 1645908] Re: Domain id reference for federated users fails in keystone middleware

[Morgan Fainberg]

Moved to keystonemiddleware project.

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

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

** No longer affects: keystone

-- 
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/1645908

Title:
  Domain id reference for federated users fails in keystone middleware

Status in keystonemiddleware:
  New

Bug description:
  Version: Keystone Mitaka

  Keystone middleware expects the domain id field to be set for a user.
  For federated users, the domain id is set to be None and hence causes
  an error during autoscaling of a Heat stack created by SSO user.

  Had to modify _populate_user() function in
  keystone/token/providers/common.py to set a dummy domain id for
  federated users as below to fix this issue:

  # Fix: domain id for federated users is None, so send dummy value.
  # Added is_local user attribute to distinguish local and federated 
users.
  if user_ref.get('is_local'):
  domain = self._get_filtered_domain(user_ref['domain_id'])
  else:
  domain = {
'id': CONF.federation.federated_domain_name,
'name': CONF.federation.federated_domain_name
   }
  # end

  Wondering if this is the right way to resolve the domain reference
  issue for SSO.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1645908/+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 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context

[Morgan Fainberg]

Turns out the issue comes from the test suite not using the AuthContext
object. A new patch to ensure we are using AuthContext not a dict will
be proposed in lieu of the current fix.

** Changed in: keystone/mitaka
   Status: In Progress => Invalid

** Changed in: keystone/newton
   Status: In Progress => 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/1656076

Title:
  The keystone server auth pluigin methods could mismatch user_id in
  auth_context

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) mitaka series:
  Invalid
Status in OpenStack Identity (keystone) newton series:
  Invalid
Status in OpenStack Identity (keystone) ocata series:
  In Progress

Bug description:
  The keystone server blindly overwrites the auth_context.user_id in
  each auth method that is run. This means that the last auth_method
  that is run for a given authentication request dictates the user_id.

  While this is not exploitable externally without misconfiguration of
  the external plugin methods and supporting services, this is a bad
  state that could relatively easily result in someone ending up
  authenticated with the wrong user_id.

  The simplest fix will be to have the for loop in the authentication
  controller (that iterates over the methods) to verify the user_id does
  not change between auth_methods executed.

  
https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557

  This has been marked as public security for hardening purposes, likely
  a "Class D" https://security.openstack.org/vmt-process.html#incident-
  report-taxonomy

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1656076/+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 1656076] Re: The keystone server auth pluigin methods could mismatch user_id in auth_context

[Morgan Fainberg]

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Also affects: keystone/newton
   Importance: Undecided
   Status: New

** Also affects: keystone/mitaka
   Importance: Undecided
   Status: New

** Also affects: keystone/ocata
   Importance: Medium
 Assignee: Morgan Fainberg (mdrnstm)
   Status: Triaged

** Changed in: keystone/newton
   Status: New => Triaged

** Changed in: keystone/newton
   Importance: Undecided => Medium

** Changed in: keystone/mitaka
   Status: New => Triaged

** Changed in: keystone/mitaka
   Importance: Undecided => Medium

** Changed in: keystone/mitaka
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

** Changed in: keystone/newton
 Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

-- 
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/1656076

Title:
  The keystone server auth pluigin methods could mismatch user_id in
  auth_context

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Identity (keystone) mitaka series:
  Triaged
Status in OpenStack Identity (keystone) newton series:
  Triaged
Status in OpenStack Identity (keystone) ocata series:
  Triaged

Bug description:
  The keystone server blindly overwrites the auth_context.user_id in
  each auth method that is run. This means that the last auth_method
  that is run for a given authentication request dictates the user_id.

  While this is not exploitable externally without misconfiguration of
  the external plugin methods and supporting services, this is a bad
  state that could relatively easily result in someone ending up
  authenticated with the wrong user_id.

  The simplest fix will be to have the for loop in the authentication
  controller (that iterates over the methods) to verify the user_id does
  not change between auth_methods executed.

  
https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557

  This has been marked as public security for hardening purposes, likely
  a "Class D" https://security.openstack.org/vmt-process.html#incident-
  report-taxonomy

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1656076/+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 1656076] [NEW] The keystone server auth pluigin methods could mismatch user_id in auth_context

[Morgan Fainberg]

*** This bug is a security vulnerability ***

Public security bug reported:

The keystone server blindly overwrites the auth_context.user_id in each
auth method that is run. This means that the last auth_method that is
run for a given authentication request dictates the user_id.

While this is not exploitable externally without misconfiguration of the
external plugin methods and supporting services, this is a bad state
that could relatively easily result in someone ending up authenticated
with the wrong user_id.

The simplest fix will be to have the for loop in the authentication
controller (that iterates over the methods) to verify the user_id does
not change between auth_methods executed.

https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557

This has been marked as public security for hardening purposes, likely a
"Class D" https://security.openstack.org/vmt-process.html#incident-
report-taxonomy

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: authentication security

** Tags added: authentication security

-- 
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/1656076

Title:
  The keystone server auth pluigin methods could mismatch user_id in
  auth_context

Status in OpenStack Identity (keystone):
  New

Bug description:
  The keystone server blindly overwrites the auth_context.user_id in
  each auth method that is run. This means that the last auth_method
  that is run for a given authentication request dictates the user_id.

  While this is not exploitable externally without misconfiguration of
  the external plugin methods and supporting services, this is a bad
  state that could relatively easily result in someone ending up
  authenticated with the wrong user_id.

  The simplest fix will be to have the for loop in the authentication
  controller (that iterates over the methods) to verify the user_id does
  not change between auth_methods executed.

  
https://github.com/openstack/keystone/blob/f8ee249bf08cefd8468aa15c589dab48bd5c4cd8/keystone/auth/controllers.py#L550-L557

  This has been marked as public security for hardening purposes, likely
  a "Class D" https://security.openstack.org/vmt-process.html#incident-
  report-taxonomy

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1656076/+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 1646273] Re: is_admin_project missing when it's not true (missing rather than false)

[Morgan Fainberg]

The other bug was/is public (as referenced in #4 by matt) and this was
specifically for newton. Marking this as invalid as this is a Class E /
"not a bug")

** Changed in: ossa
   Status: Incomplete => 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/1646273

Title:
  is_admin_project missing when it's not true (missing rather than
  false)

Status in OpenStack Identity (keystone):
  Invalid
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  After setting the admin_project_name = admin and
  admin_project_domain_name = Default in keystone.conf, I generated some
  tokens in the admin project. Then I validated the tokens. These tokens
  properly include the is_admin_project: true information.

  Correct token:  http://paste.openstack.org/show/591031/

  Then I switched to the "bob" project and generated and then validated
  a token. I was admin in both projects. My "bob" project token is
  missing the is_admin_project field completely. This unfortunately then
  causes the oslo.context middleware to assume that you are in an admin
  project (context assumes missing = true).

  Bob token, aka, where's the is_admin_project_field?:
  http://paste.openstack.org/show/591034/

  We're on stable/newton running on commit
  3609439599571a5919c4e1d328c1f06a8e4422c9

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1646273/+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 1259011] Re: Certificates cannot be retrieved from the V3 API

[Morgan Fainberg]

With PKI tokens being deprecated, I am going to mark this as "wont fix",
prefering Fernet and/or UUID tokens to PKI

** Changed in: keystonemiddleware
   Status: Triaged => Won't Fix

-- 
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/1259011

Title:
  Certificates cannot be retrieved from the V3 API

Status in OpenStack Identity (keystone):
  Fix Released
Status in keystonemiddleware:
  Won't Fix
Status in openstack-api-site:
  Fix Released

Bug description:
  Auth_token middleware relies upon the V2 api to provide the
  certificates that are required to validate PKI tokens because this
  information is not provided by the V3 API.

  Longer term i think we should be encouraging deployers to handle their
  own certificate distribution as fetching the certificates from the
  same source that is issuing tokens is not secure, however for the mean
  time we need some way of providing these certificates to token
  validators.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1259011/+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 1571150] Re: login as admin to projects fails

[Morgan Fainberg]

As an additional note this would not affect keystoneauth but affect
keystone from what I can tell. Your logs will help us significantly.
I've retargeted the bug to keystone instead of keystoneauth, pending
your log files.

** Project changed: keystoneauth => keystone

-- 
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/1571150

Title:
  login as admin to projects fails

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  Incomplete

Bug description:
  create project:
  1)login as admin.
  2)add project, add admin as member to that project.
  3)logout

  recreate bug:
  2.1)login as admin.
  2.2)from "projects" on top left choose the project.
  2.3)you are "unauthorized" and sent out 
  2.4)try login again (no change to url) - unsuccessful ...
  2.5)change url back to root level, login again, and you are now authorized 
inside the project.

  repeat 2.1 to 2.5 many times same results

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1571150/+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 1570463] Re: RFE: keystone-manage CLI to allow using syslog & specific log files

[Morgan Fainberg]

The fernet keys should not be writable by the keystone user, typically
by root (same as a certificate), therefore the log should likewise be
separate to avoid breaking normal logging.

The use of syslog would easily solve this issue.

** Tags added: fernet logging low-hanging-fruit

** Changed in: keystone
   Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Also affects: keystone/newton
   Importance: Medium
   Status: Triaged

-- 
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/1570463

Title:
  RFE: keystone-manage CLI to allow using syslog & specific log files

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Identity (keystone) newton series:
  Triaged

Bug description:
  Currently, keystone-manage CLI tool will by default write in
  $log_dir/$log_file, which is most of the case /var/log/keystone.log.

  Some actions (like fernet keys generations) are dynamic, and having
  them in a separated logfile would be a nice feature for operators.
  Also supporting syslog would be very helpful for production
  deployments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1570463/+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