Bug 109 - unitiailized gid when writing a user profile
unitiailized gid when writing a user profile
Status: VERIFIED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.0preX
All other
: P2 critical
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-22 12:23 UTC by Gerald (Jerry) Carter
Modified: 2005-11-14 09:29 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald (Jerry) Carter 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 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 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 2003-07-06 20:51:55 UTC
works fine in latest CVS
Comment 9 Gerald (Jerry) Carter 2005-02-07 08:38:50 UTC
originally reported against 3.0.0beta1.  CLeaning out 
non-production release versions.
Comment 10 Gerald (Jerry) Carter 2005-11-14 09:29:48 UTC
database cleanup