Bug 823740 - Read valid admin list from /etc/pulpdist/site.conf
Read valid admin list from /etc/pulpdist/site.conf
Status: CLOSED NEXTRELEASE
Product: PulpDist
Classification: Community
Component: Web App (Show other bugs)
unspecified
Unspecified Unspecified
high Severity high
: 0.1.0
: ---
Assigned To: Nick Coghlan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-21 23:08 EDT by Marco Grigull
Modified: 2012-05-23 01:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-23 01:46:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marco Grigull 2012-05-21 23:08:07 EDT
Description of problem:
not accepting admin access when listed only in that file

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


Additional info:
It is blocking the ability to roll out to stage for preliminary evaluation.
Comment 1 Nick Coghlan 2012-05-21 23:14:46 EDT
Note that the existing scheme should already automatically flag a user as an administrator based on the [admin] section in site.conf if they haven't logged into the site before.

It's only the case where someone changes from being a normal user to an admin user that currently requires a manual workaround:

1. Log into the site as an existing admin user
2. Click on the Site Admin link
3. Use the Django Admin UI to find the User entry for the new administrator
4. Change their status to mark them as a staff member and super user

I agree that this is annoying and the authentication backend should just update their user status automatically next time they log in, but it shouldn't be a blocker for anything.

The auto update will be in place for 0.0.16, but running a staging instance on 0.0.15 should be quite feasible.
Comment 2 Nick Coghlan 2012-05-21 23:25:58 EDT
As a potentially simpler workaround, it's possible to nuke all existing user entries, so they get recreated based on site.conf at next login:

$ python -m pulpdist.manage_site dbshell
SQLite version 3.6.20
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> delete from auth_user;

The recreation of the user with the correct permissions will then happen automatically next time the user logs in.
Comment 3 Nick Coghlan 2012-05-22 05:25:06 EDT
Dynamic updates have been added for 0.0.16, but it's still necessary to clear any active Django sessions to ensure that affected users are reauthenticated even if they have been logged into the web UI recently.

The relevant command is:

echo "delete from django_session;" | sudo python -m globalsync.manage_site dbshell

Leaving as modified until docs have been updated appropriately.
Comment 4 Nick Coghlan 2012-05-23 01:46:01 EDT
Rather than adjusting the docs, pulpdist-httpd has been updated to use memory backed sessions instead of database backed ones. This means restarting the web server will automatically drop any sessions, ensuring that permissions changes are picked up immediately.

The assumed use of Kerberos authentication with pulpdist-httpd means that end users shouldn't notice anything. For other usage scenarios, people can consult the Django docs to decide for themselves how they want to handle authentication, sessions, permissions and caching.

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