Bug 652763 - The 'principal' stored in thread data contains leftover (stale) data
Summary: The 'principal' stored in thread data contains leftover (stale) data
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Pulp
Classification: Retired
Component: z_other
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Mike McCune
QA Contact: Preethi Thomas
URL:
Whiteboard:
Depends On:
Blocks: verified-to-close
TreeView+ depends on / blocked
 
Reported: 2010-11-12 17:50 UTC by Jeff Ortel
Modified: 2011-08-16 14:19 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-16 14:19:57 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.