Bug 5696 - force group fails at smbd/service.c:find_forced_group(606)
force group fails at smbd/service.c:find_forced_group(606)
Status: RESOLVED FIXED
Product: Samba 3.2
Classification: Unclassified
Component: User & Group Accounts
3.2.1
PPC AIX
: P3 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-16 12:24 UTC by Devin Nate
Modified: 2008-08-20 08:27 UTC (History)
0 users

See Also:


Attachments
Patch (1.17 KB, patch)
2008-08-16 21:26 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Devin Nate 2008-08-16 12:24:54 UTC
using force group = ccdb paramater.

Call appears to fail because ccdb is both a user and a group. Relavent log at debug level = 10


[2008/08/16 14:15:05,  5] smbd/uid.c:change_to_root_user(287)
  change_to_root_user: now uid=(0,0) gid=(0,0)
[2008/08/16 14:15:05,  4] smbd/reply.c:reply_tcon_and_X(653)
  Client requested device type [?????] for share [NETWORK]
[2008/08/16 14:15:05,  5] smbd/service.c:make_connection(1376)
  making a connection to 'normal' service network
[2008/08/16 14:15:05,  5] lib/username.c:Get_Pwnam_alloc(133)
  Finding user guest
[2008/08/16 14:15:05,  5] lib/username.c:Get_Pwnam_internals(77)
  Trying _Get_Pwnam(), username as lowercase is guest
[2008/08/16 14:15:05,  5] lib/username.c:Get_Pwnam_internals(110)
  Get_Pwnam_internals did find user [guest]!
[2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(69)
  lookup_name: CCSERVER\ccdb => CCSERVER (domain), ccdb (name)
[2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(70)
  lookup_name: flags = 0x077
[2008/08/16 14:15:05,  3] smbd/sec_ctx.c:push_sec_ctx(224)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2008/08/16 14:15:05,  3] smbd/uid.c:push_conn_ctx(357)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2008/08/16 14:15:05,  3] smbd/sec_ctx.c:set_sec_ctx(324)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2008/08/16 14:15:05,  5] auth/token_util.c:debug_nt_user_token(464)
  NT user token: (NULL)
[2008/08/16 14:15:05,  5] auth/token_util.c:debug_unix_user_token(490)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2008/08/16 14:15:05,  3] smbd/sec_ctx.c:pop_sec_ctx(432)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(69)
  lookup_name: Unix Group\ccdb => Unix Group (domain), ccdb (name)
[2008/08/16 14:15:05, 10] passdb/lookup_sid.c:lookup_name(70)
  lookup_name: flags = 0x077
[2008/08/16 14:15:05, 10] smbd/service.c:find_forced_group(606)
  ccdb is a User, not a group
[2008/08/16 14:15:05,  3] smbd/error.c:error_packet_set(61)
  error packet at smbd/reply.c(662) cmd=117 (SMBtconX) NT_STATUS_NO_SUCH_GROUP
[2008/08/16 14:15:05,  5] lib/util.c:show_msg(645)
[2008/08/16 14:15:05,  5] lib/util.c:show_msg(655)
Comment 1 Jeremy Allison 2008-08-16 15:25:42 UTC
This is strange. It's definately looking for a Unix group, see the line :

lookup_name: Unix Group\ccdb => Unix Group (domain), ccdb

is winbindd running ? Looks to me like the only way this can happen is by the call to winbind_lookup_name() here :

 103         if ((domain[0] != '\0') &&
 104             (flags & ~(LOOKUP_NAME_DOMAIN|LOOKUP_NAME_ISOLATED)) &&
 105             (winbind_lookup_name(domain, name, &sid, &type))) {
 106                         goto ok;
 107         }

If you explicitly qualify the name in smb.conf with "Unix Group\ccdb" does this fix the problem ?

Jeremy.
Comment 2 Jeremy Allison 2008-08-16 16:13:55 UTC
Ok, without winbindd running I can't reproduce your problem on my local box here. I get (for a share with "force group = +jeremy" and logging in with user jeremy:

  user_ok_token: share tmp is ok for unix user jeremy
[2008/08/16 13:50:15,  5] lib/username.c:Get_Pwnam_alloc(133)
  Finding user jeremy
[2008/08/16 13:50:15,  5] lib/username.c:Get_Pwnam_internals(77)
  Trying _Get_Pwnam(), username as lowercase is jeremy
[2008/08/16 13:50:15,  5] lib/username.c:Get_Pwnam_internals(110)
  Get_Pwnam_internals did find user [jeremy]!
[2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(69)
  lookup_name: JEREMY2\jeremy => JEREMY2 (domain), jeremy (name)
[2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(70)
  lookup_name: flags = 0x077
[2008/08/16 13:50:15,  3] smbd/sec_ctx.c:push_sec_ctx(224)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2008/08/16 13:50:15,  3] smbd/uid.c:push_conn_ctx(357)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2008/08/16 13:50:15,  3] smbd/sec_ctx.c:set_sec_ctx(324)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2008/08/16 13:50:15,  5] auth/token_util.c:debug_nt_user_token(464)
  NT user token: (NULL)
[2008/08/16 13:50:15,  5] auth/token_util.c:debug_unix_user_token(490)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2008/08/16 13:50:15,  3] smbd/sec_ctx.c:pop_sec_ctx(432)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(69)
  lookup_name: Unix Group\jeremy => Unix Group (domain), jeremy (name)
[2008/08/16 13:50:15, 10] passdb/lookup_sid.c:lookup_name(70)
  lookup_name: flags = 0x077
[2008/08/16 13:50:15, 10] passdb/lookup_sid.c:sid_to_gid(1413)
  sid S-1-22-2-1000 -> gid 1000
Comment 3 Jeremy Allison 2008-08-16 17:14:33 UTC
Ok, with winbindd running I can reproduce this. Give me a few hours to fix this.
Jeremy.
Comment 4 Jeremy Allison 2008-08-16 21:26:50 UTC
Created attachment 3485 [details]
Patch

Ok, the fix is attached. The problem was when smbd
was asking for a winbindd name to SID lookup of
"Unix Group\name" where "name" was also a valid username,
the winbindd passdb lookup of that name was losing the
domain string info before calling lookup name (ie. lookup_name()
was being called with just the string "name", not the
full string "Unix Group\name").

The passdb backend of winbindd has to cope with
not only names from it's own global SAM domain,
but it does lookups for BUILTIN and "Unix User"
and "Unix Group" also, so making it guess by
losing the domain string is "A Bad Idea" (tm) :-).

Note that as winbind globally calls winbind_off()
at startup, it's safe for winbind to call sys_getgrnam()
to do the "Unix Group" lookup from inside lookup_name().
Comment 5 Devin Nate 2008-08-17 16:23:47 UTC
Thanks so much Jeremy. Would you like me to test it, or wait until 3.2.2?
Again, thanks for the speedy work.

By the way, I tested in 3.0.31 and 3.0.28a and the problem appeared there also.

That said, I see you saying there's a difference with/without winbindd running. What is the preferred role for winbindd, is there ever a time when it's good not to run it? Let me know or if there's a faq or good reading on it.

Thanks,
Devin Nate
Comment 6 Jeremy Allison 2008-08-18 12:13:02 UTC
Well more testing is always good :-). The patch works for me but I'd also like to hear if it works for you. I'll look into adding it to the 3.0.x codebase (now in maintanence mode).
Cheers,
Jeremy.
Comment 7 Devin Nate 2008-08-18 12:57:18 UTC
The patch worked for me also against a clean 3.2.1. (which is what we use).

Thanks!
Devin Nate
Comment 8 Karolin Seeger 2008-08-20 08:27:25 UTC
Closing out bug report.

Thanks for reporting!