Bug 652763

Summary:	The 'principal' stored in thread data contains leftover (stale) data
Product:	[Retired] Pulp	Reporter:	Jeff Ortel <jortel>
Component:	z_other	Assignee:	Mike McCune <mmccune>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Preethi Thomas <pthomas>
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	Keywords:	Triaged
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-16 14:19:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	647488

Description Jeff Ortel 2010-11-12 17:50:02 UTC

Description of problem:

The 'principal' stored in thread data contains leftover (stale) data.  Since it is only updated by role_check when the user is the admin, it is never set/cleared in other cases.  As a result, the principal is left in the thread data.  Subsequent REST calls (not admin) that grab that thread from the pool, use the previous principal as the principal for the current role check.

Version-Release number of selected component (if applicable):


How reproducible:

It's kind of tricky because you need to somehow get the admin user in *some* of the apache worker threads but not all.  Then, you need to logout and do pulp-client commands using a non-pulp created consumer certificate.  I used a candlepin consumer certificate which does not contain the user info as expected by pulp.  Evidence of this problem was consumer_history raising an exception when no principal was found in some runs but not in others.  See attached.

Steps to Reproduce:
1. bounce httpd
2. login as 'admin'
3. run a few pulp-admin or pulp-client commands.
4. logout
5. create user 'foo'
6. login as 'foo'
7. run pulp-admin repo list' several times (over and over)
  
Actual results:

Command succeeds even though you are not logged in as 'admin' but server finds the old 'admin' principal in the thread data and permit the command.

Expected results:

Should fail with auth exception.

Additional info:

Comment 1 Jeff Ortel 2010-11-12 18:08:40 UTC

To support using candlepin consumer (client) certificates, role_check needs to lookup the user using the consumer ID rather then depending on the user being stored in the client cert.

Comment 2 Jeff Ortel 2010-11-17 17:06:07 UTC

Fixed with update to certificate authentication and principal management.
commit: 7b8320d39b99eda57adfe85646166d34f2e3b4da

Comment 3 Jay Dobies 2010-11-29 14:15:52 UTC

Fixed in 0.109.

Comment 4 Preethi Thomas 2011-07-25 14:41:34 UTC

verified
[root@preethi ~]# rpm -q pulp
pulp-0.0.213-1.fc14.noarch
[root@preethi ~]# 

[root@preethi ~]# pulp-admin auth logout
User credentials removed from [/root/.pulp/user-cert.pem]

[root@preethi ~]# 
[root@preethi ~]# 
[root@preethi ~]# 
[root@preethi ~]# pulp-admin repo list
error: operation failed: No valid authorization credentials found, please see: pulp-admin --help
[root@preethi ~]# 
[root@preethi ~]# 
[root@preethi ~]# pulp-admin -u foo -p bar repo list
error: operation failed: Permission Denied

Comment 5 Preethi Thomas 2011-08-16 14:19:57 UTC

Closing with Community Release 15

pulp-0.0.223-4.