Issue #593
closed
username key in permissions preventing '.' in username.
Description
Description of problem:
The way mongo handles key/values prevents a key from containing a '.', and in the permissions data structure there is a key/value pair with username as the key. This causes an error during permissions creation when username contains a '.'.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Clone https://github.com/pcreech/pulp.git and switch to branch pcreech-1113629 or use pull request https://github.com/pulp/pulp/pull/1265
2. $ pulp-admin auth user create --login test.user
3. Enter password
4. Re-Enter password
Actual results:
->An internal error occurred on the Pulp server:
->RequestException: POST request
->on /pulp/api/v2/users/ failed with 500 - key 'test.user' must not contain '.'
Expected results:
User [test.user] successfully created
Additional info:
I've narrowed it down to when the user's permissions get created. The user object iself is created successfully in db.users table.
The options I have come up with to handle this so far are:
1. Switch to tying permissions to something other than the login
(this will require existig databases to be modified, and introduces
potential errors on production machines)
2. Find a way to encode the '.' in the username to a different character,
possibly one that's an 'invalid' character in the username so there is no
chance of character overlap.
3. Continue restricting '.' from username
+ This bug was cloned from Bugzilla Bug #1158138 +
Updated by amacdona@redhat.com about 9 years ago
***** Bug 1113629 has been marked as a duplicate of this bug. ***
+ This comment was cloned from Bugzilla #1158138 comment 1 +
Updated by amacdona@redhat.com about 9 years ago
https://github.com/pulp/pulp/pull/1299
+ This comment was cloned from Bugzilla #1158138 comment 2 +
Updated by cduryee about 9 years ago
fixed in pulp 2.6.0-0.2.beta
+ This comment was cloned from Bugzilla #1158138 comment 3 +
Updated by igulina@redhat.com about 9 years ago
I could create the user 'test.user'. I could create the user whose id is a single period. Then it's not possible to delete this period id user.
rpm -qa | grep pulp-server
pulp-server-2.6.0-0.2.beta.fc20.noarch
pulp-admin auth user create --login test.user
Enter password for user [test.user] :
Re-enter password for user [test.user]:
User [test.user] successfully created
pulp-admin auth user list
--------------------------------------------------------------------
Users
--------------------------------------------------------------------
Login: admin
Name: admin
Login: test.user
Name: test.user
Login: test
Name: test
pulp-admin auth permission grant --resource /v2/repositories/ --login test.user -o create -o update -o read
Permissions [/v2/repositories/ : ['CREATE', 'UPDATE', 'READ']] successfully
granted to user [test.user]
pulp-admin -u test.user -p 123 repo list
--------------------------------------------------------------------
Repositories
--------------------------------------------------------------------
pulp-admin auth user delete --login test.user
User [test.user] successfully deleted
pulp-admin auth user create --login .
Enter password for user [.] :
Re-enter password for user [.]:
User [.] successfully created
pulp-admin auth user list --details
--------------------------------------------------------------------
Users
--------------------------------------------------------------------
Login: admin
Name: admin
Roles: super-users
Login: test
Name: test
Roles:
Login: .
Name: .
Roles:
pulp-admin auth user delete --login .
There was an internal server error while trying to access the Pulp application.
One possible cause is that the database needs to be migrated to the latest
version. If this is the case, run pulp-manage-db and restart the services. More
information may be found in Apache's log.
There is exactly the same issue with a period id repo
https://bugzilla.redhat.com/show_bug.cgi?id=1159071
What to do?
- Move this bug to VERIFIED and open a new one about 'period' user? or
- Move this bug back to ASSIGN?
+ This comment was cloned from Bugzilla #1158138 comment 4 +
Updated by igulina@redhat.com about 9 years ago
Moving to verified according to the comment [1] on BZ 1159071.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1159071#c2
+ This comment was cloned from Bugzilla #1158138 comment 5 +
Updated by rbarlow about 9 years ago
- Status changed from 6 to CLOSED - CURRENTRELEASE
Updated by bmbouter almost 4 years ago
- Category deleted (
14)
We are removing the 'API' category per open floor discussion June 16, 2020.
.