Bug 888066

Summary:	Log entry when a regular user does "keystone user-list" is not helpful
Product:	Red Hat OpenStack	Reporter:	Russell Bryant <rbryant>
Component:	openstack-keystone	Assignee:	Adam Young <ayoung>
Status:	CLOSED WONTFIX	QA Contact:	Ami Jeain <ajeain>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	dpal, nkinder, yeylon
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	5.0 (RHEL 7)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-02-27 15:45:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Russell Bryant 2012-12-17 23:15:42 UTC

"keystone user-list" is an admin only command.  When a regular user tries to execute it, you get a helpful response at the command line:

[root@rhel ~(keystone_username)]# keystone user-list
You are not authorized to perform the requested action: admin_required (HTTP 403)

However, this same message is in /var/log/keystone/keystone.log:

2012-12-17 17:27:29  WARNING [keystone.common.wsgi] You are not authorized to perform the requested action: admin_required

This log entry is not helpful.  As an administrator, all this tells you is that *someone* tried to execute *something* that they weren't allowed to.  Without any information about who or what, the log entry isn't useful.

Comment 2 Alan Pevec 2013-02-19 00:33:33 UTC

> This log entry is not helpful.  As an administrator, all this tells you is
> that *someone* tried to execute *something* that they weren't allowed to. 
> Without any information about who or what, the log entry isn't useful.

keystone.exception.ForbiddenAction records only action, adding more context requires upstream changes in policy engine

Comment 4 Nathan Kinder 2014-02-27 15:45:01 UTC

This was closed as WONTFIX upstream, as the issue only affects the v2 API (the problem is not present in v3).  Closing this as WONTFIX as well, as this doesn't seem like it's a critical issue.