Bug 267 - Users supplementary domain groups not added
Users supplementary domain groups not added
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.0preX
Other other
: P1 normal
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-02 09:00 UTC by Gerald (Jerry) Carter
Modified: 2005-08-24 10:21 UTC (History)
2 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-08-02 09:00:36 UTC
The user's supplementary domain groups aren't being converted to 
GIDs in SAMBA_3_0.  The SIDs are saved in the nt_user_token, but 
they're never added to the Unix group list.  These are needed for 
ACL checks and probably other things.

Calling to add_supplementary_nt_login_groups at the end of
make_server_info_info3 in auth_util.c seems to do the trick, 
but I'm not sure why it has been excluded in the past.

Add this to the end of make_server_info_info3 in auth_util.c:

    add_supplementary_nt_login_groups(&(*server_info)->n_groups,
        &(*server_info)->groups, &token);
Comment 1 Tim Potter 2003-08-05 18:54:03 UTC
Ken, I'm unable to reproduce this from the latest CVS.  A user who is a member
of no extra groups is given the token:

NT user token of user S-1-5-21-1606980848-1677128483-854245398-1149
contains 5 SIDs
SID[  0]: S-1-5-21-1606980848-1677128483-854245398-1149
SID[  1]: S-1-5-21-1606980848-1677128483-854245398-513
SID[  2]: S-1-1-0
SID[  3]: S-1-5-2
SID[  4]: S-1-5-11
UNIX token of user 10017
Primary group is 10000 and contains 2 supplementary groups
Group[  0]: 10000
Group[  1]: 10000

If I add the user to a group and re-authenticate I get this token:

NT user token of user S-1-5-21-1606980848-1677128483-854245398-1149
contains 6 SIDs
SID[  0]: S-1-5-21-1606980848-1677128483-854245398-1149
SID[  1]: S-1-5-21-1606980848-1677128483-854245398-513
SID[  2]: S-1-1-0
SID[  3]: S-1-5-2
SID[  4]: S-1-5-11
SID[  5]: S-1-5-21-1606980848-1677128483-854245398-1127
UNIX token of user 10017
Primary group is 10000 and contains 3 supplementary groups
Group[  0]: 10000
Group[  1]: 10000
Group[  2]: 10010
Comment 2 Tim Potter 2003-08-05 18:55:56 UTC
cc me
Comment 3 Ken Cross 2003-08-05 19:46:58 UTC
Hmm.  Here is what I got *before* I added my patch:

[2003/07/28 14:54:48, 5] auth/auth_util.c:debug_unix_user_token(504)
  UNIX token of user 100003
  Primary group is 202052 and contains 1 supplementary groups
  Group[  0]: 202052
[2003/07/28 14:54:48, 10] auth/auth_util.c:debug_nt_user_token(490)
  NT user token of user S-1-5-21-2220038185-3617674260-943656220-500
  contains 9 SIDs
  SID[  0]: S-1-5-21-2220038185-3617674260-943656220-500
  SID[  1]: S-1-5-21-2220038185-3617674260-943656220-513
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-5-21-2220038185-3617674260-943656220-512
  SID[  6]: S-1-5-21-2220038185-3617674260-943656220-519
  SID[  7]: S-1-5-21-2220038185-3617674260-943656220-520
  SID[  8]: S-1-5-21-2220038185-3617674260-943656220-518

I'll have to get the latest cvs and remove my change before testing again.
Comment 4 Tim Potter 2003-08-05 21:18:32 UTC
I also noticed that the add_supplementary_nt_login_groups() isn't actually
called from anywhere.  Presumably it used to though.
Comment 5 Ken Cross 2003-08-06 05:48:10 UTC
When I removed my patch, it still don't get the user's groups.  But I may have 
some other problem.  Now I get:

[2003/08/05 23:00:10, 5] auth/auth_util.c:debug_unix_user_token(505)
  UNIX token of user 100003
  Primary group is 202052 and contains 1 supplementary groups
  Group[  0]: 202052

[2003/08/05 23:00:10, 3] lib/util_seaccess.c:se_access_check(268)
  se_access_check: user sid is S-1-5-21-2220038185-3617674260-943656220-500
  se_access_check: also S-1-5-21-2220038185-3617674260-943656220-513
  se_access_check: also S-1-1-0
  se_access_check: also S-1-5-2
  se_access_check: also S-1-5-11
  se_access_check: also S-1-5-21-2220038185-3617674260-943656220-512
  se_access_check: also S-1-5-21-2220038185-3617674260-943656220-519
  se_access_check: also S-1-5-21-2220038185-3617674260-943656220-520
  se_access_check: also S-1-5-21-2220038185-3617674260-943656220-518

Note that it's se_access_check.  There was no display of the NT user token at 
all.  There are lots of paths that could cause that, so it'll take some 
digging.
Comment 6 Gerald (Jerry) Carter 2003-08-07 15:45:57 UTC
Ken, Are you running in domain mode with winbindd?
Tim, what was your setup like?  

I've got a hunch that this is the difference.
Comment 7 Gerald (Jerry) Carter 2003-08-07 21:40:27 UTC
what platform are you running on?  I noticed that initialise_groups()
has had the winbind_initgroups() called removed and replaced with a simple
initgroups().  

Ahh...I'll bet it is a problem with libc running through getgrent 
and finding all the secondary groups groups on your platform.
Does the domain server have RestrictAnonymous set?

If we make initializse_groups() in the current code match what 
it did in 2.2 we should be ok, because winbind_getgroups() grabs 
the users group membership from the cached info3 struct returned
by the net_sam_logon() reply.
Comment 8 Ken Cross 2003-08-08 05:20:29 UTC
I'm running on NetBSD, with winbindd in domain/ads mode.

NetBSD doesn't support nsswitch.  So I've had to hack libc directly to add 
support for getgrent, getpwent, etc.  It's worked fine until recently, though, 
so you've probably spotted the change.

OTOH, if this is a problem peculiar to me, I can take care of it locally.  I 
wanted to make sure it wasn't a more generic problem, though.
Comment 9 Gerald (Jerry) Carter 2003-08-09 15:33:53 UTC
I'm putting in place work around to make us more robust 
on systems where the secondary group lookups fail
through glibc.  Besides we have all this information
stored in netsamlogon_cache.tdb after a user first 
logs onto the system.  Much more effecient that getgrent().

Ken tested the patch and it works for his case.
Comment 10 Tim Potter 2003-08-11 17:18:17 UTC
For the record, my setup was winbindd in rpc domain on Linux.
Comment 11 Gerald (Jerry) Carter 2005-02-07 08:41:32 UTC
originally reported against 3.0.0beta3.  CLeaning out 
non-production release versions.
Comment 12 Gerald (Jerry) Carter 2005-08-24 10:21:13 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.