Bug 109 - unitiailized gid when writing a user profile
Summary: unitiailized gid when writing a user profile
Status: VERIFIED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.0preX
Hardware: All other
: P2 critical
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-22 12:23 UTC by Gerald (Jerry) Carter (dead mail address)
Modified: 2005-11-14 09:29 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald (Jerry) Carter (dead mail address) 2003-05-22 12:23:57 UTC 
Client is WinXP SP1.  Profile directory shows 
up like

drwx------+   2 jerry    2147483404     4096 05-22 14:14 WinXP/


2.4.20+acl kernel.  Samba_3_0 cvs code as of today 
(2003-05-22)
Comment 1 Andrew Bartlett 2003-05-30 19:51:38 UTC 
Looks like the issue from the sid_to_gid code not having a valid mapping. 
Particularly the pdb_ldap bugs that we had in this area.  Should also be better
with idmap_ldap in (what happened to that?)
Comment 2 Andrew Bartlett 2003-06-21 19:22:13 UTC 
I'm told that this should be fixed with idra's new idmap patch.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2003-06-26 08:36:17 UTC 
not fixed.  Working on it now.

$ ls -ld test
drwxr-xr-x    2 jerry    2147483404     4096 06-26 10:19 test/
Comment 4 Gerald (Jerry) Carter (dead mail address) 2003-06-30 22:46:21 UTC 
sent to samba-technical....

------ original message ---------------------
I've found the cause of this bug.  It is the call to sid_to_gid()
in make_server_info_sam().  Probably appears elsewhere as well.
When using an ldapsam backend, if the sambaPrimaryGroupSID is unmapped,
we'll drop back to the algorithm is generating gids.

We seem to set DOMAIN_GROUP_USERS as the primary group for new
entries in several backends.  Do we even really need this attribute?
Shouldn't we be deriving it from the primary UNIX group of the user
and let the group mapping handle things.  We can store it in SAM_ACCOUNT
for quickness.  That's ok.  But actually storing a SID that may not be
mapped to the user's primary UNIX group seems inconsistent with other
behavior.

Can one of you convince me that we we shouldn't just throw away this
attribute value in the code and just generate the SID from the primary
gid of the user?  As it stands now, it is possible (and probable
in default installations) that the group membership Samba is using does
not match the UNIX group membership of the user.
Comment 5 Andrew Bartlett 2003-07-04 07:11:08 UTC 
Recent changes have occoured to the symptom of this bug.

You will no longer get an 'uninitialised' GID, you will be allocated a GID out
of the GID pool specified with 'idmap gid'.
Comment 6 Andrew Bartlett 2003-07-05 22:53:46 UTC 
I think I have fixed this up, restoring previous behaviour where the user's unix
primary group is used regardless.

However, I'll leave this bug open, as it looks like other work is happening here
that might cause the revertion of these changes.
Comment 7 Andrew Bartlett 2003-07-05 23:25:22 UTC 
Oops, I closed it.  I think it's safe to say that it's closed anyway.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2003-07-06 20:51:55 UTC 
works fine in latest CVS
Comment 9 Gerald (Jerry) Carter (dead mail address) 2005-02-07 08:38:50 UTC 
originally reported against 3.0.0beta1.  CLeaning out 
non-production release versions.
Comment 10 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:29:48 UTC 
database cleanup