Bug 5119 - pdbedit assigns wrong rid for user accounts, should be 2*UID+1000
pdbedit assigns wrong rid for user accounts, should be 2*UID+1000
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
x64 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2007-12-04 16:55 UTC by robert spitzenpfeil
Modified: 2007-12-05 08:37 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description robert spitzenpfeil 2007-12-04 16:55:47 UTC
adding user accounts with pdbedit using tdbsam backend does not stick to RID = 2*UID+1000.

this causes problems, as RIDs can get odd numbers and cannot be distinguished from groups.

right now I added a test user which got a RID of 1029 (UID = 1204, so it should get 3408).
deleting this user and re-adding it ends up with a RID of 1030
repeating this procedure subsequently increased the assigned RID by 1.

1029, 1030, 1031, 1032, 1033 and so forth.

when using smbpasswd the rid gets assigned as expected !

as a consequence of this bug, exporting to a different backend fails for users with an odd ridd.

example: test_user with UID 1204 and wrong RID of 1033

pdbedit -e smbpasswd:/samba-users.backup

--> Importing accout for test_user...failed

manually changing the RID to its correct value with 'pdbedit -U' throws an error:

pdbedit -r -u test_user -U 'S-1-5-21-XXXXX-YYYYY-ZZZZZ-3408'

Unable to modify TDB passwd ! Error: Record does not exist
occured while storing the RID index (RID_00000d50)
Unable to modify entry!

the correct RID is set though.
Comment 1 Gerald (Jerry) Carter 2007-12-04 17:00:48 UTC
This is by design.  Please read the releases for the 3.0.23 series.
Comment 2 robert spitzenpfeil 2007-12-05 08:37:19 UTC
a bug by design ?


a) inconsistent between pdbedit and smbpasswd (tdbsam passwd backend)
b) smbpasswd throws an error with rid values you claim to be correct as of 3.0.23 when exporting the database
c) if for some reason a groupmapping already exists with e.g. a rid of 3002 (now possible without group rid=2*uid+1001) smbpasswd will happily assign this rid already used for a group to a newly added user with a uid of 1001 !
(this double assignment does not occur with pdbedit, which seems to be aware of already used group rids).