Bug 764908 (GLUSTER-3176) - object-strorage: able to create many users with same uid and gid
Summary: object-strorage: able to create many users with same uid and gid
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-3176
Product: GlusterFS
Classification: Community
Component: object-storage
Version: pre-release
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gaurav
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-15 11:26 UTC by Saurabh
Modified: 2011-08-03 04:47 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Saurabh 2011-07-15 11:26:20 UTC
I have an drep and I have several created users inside it with same uid, gid and this should not happen, the uid should always be different.


root@Unbuntu:~# swauth-list -K sj -A https://127.0.0.1:443/auth drep
{"services": {"storage": {"default": "local", "local": "https://10.1.12.25:443/v1/AUTH_drep"}}, "account_id": "AUTH_drep", "users": [{"name": "reseller"}, {"name": "tester"}, {"name": "tester1"}]}


root@Unbuntu:~# swauth-list -K sj -A https://127.0.0.1:443/auth drep reseller
{"groups": [{"name": "drep:reseller"}, {"name": "drep"}, {"name": ".admin"}, {"name": ".reseller_admin"}], "gid": "100", "uid": "100", "auth": "plaintext:reselling"}


root@Unbuntu:~# swauth-list -K sj -A https://127.0.0.1:443/auth drep tester
{"groups": [{"name": "drep:tester"}, {"name": "drep"}, {"name": ".admin"}], "gid": "100", "uid": "100", "auth": "plaintext:testing"}


root@Unbuntu:~# swauth-add-user -a -K sj -A https://127.0.0.1:443/auth drep tester1 testing1 100 100

root@Unbuntu:~# swauth-list -K sj -A https://127.0.0.1:443/auth drep tester1
{"groups": [{"name": "drep:tester1"}, {"name": "drep"}, {"name": ".admin"}], "gid": "100", "uid": "100", "auth": "plaintext:testing1"}


root@Unbuntu:~#

Comment 1 Gaurav 2011-07-18 05:47:42 UTC
This is expected behaviour.


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