Bug 703 - Lookup of Windows userids in UNIX netgroups uses wrong case
Summary: Lookup of Windows userids in UNIX netgroups uses wrong case
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.0
Hardware: All Solaris
: P2 critical
Target Milestone: none
Assignee: Jeremy Allison
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-31 07:07 UTC by Eric Boehm
Modified: 2005-08-24 10:17 UTC (History)
0 users

See Also:


Attachments
Proposed patch. (1.31 KB, patch)
2003-11-04 10:23 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Boehm 2003-10-31 07:07:03 UTC
I am unable to access a share with a valid users directive from Windows but I
can access the share using smbclient from the Samba server.

Some level 10 log information

[2003/10/31 09:51:32, 5, pid=28744] auth/auth_util.c:(216)
  make_user_info_map: Mapping user [AMERICASE]\[BOEHM] from workstation [BOEHM-1]

[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(288)
  Finding user AMERICASE\BOEHM
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(223)
  Trying _Get_Pwnam(), username as lowercase is americase\boehm
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(230)
  Trying _Get_Pwnam(), username as given is AMERICASE\BOEHM
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(247)
  Checking combinations of 0 uppercase letters in americase\boehm
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(251)
  Get_Pwnam_internals didn't find user [AMERICASE\BOEHM]!
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(288)
  Finding user BOEHM
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(223)
  Trying _Get_Pwnam(), username as lowercase is boehm
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(251)
  Get_Pwnam_internals did find user [BOEHM]!
[2003/10/31 09:51:33, 10, pid=28744] passdb/pdb_get_set.c:(593)
  pdb_set_username: setting username boehm, was 
[2003/10/31 09:51:33, 10, pid=28744] passdb/pdb_get_set.c:(493)
  element 11 -> now SET
[2003/10/31 09:51:33, 10, pid=28744] passdb/pdb_get_set.c:(674)
  pdb_set_full_name: setting full name Eric Boehm, was 

[2003/10/31 09:51:33, 5, pid=28744] auth/auth_util.c:(505)
  UNIX token of user 20718
  Primary group is 2245 and contains 2 supplementary groups
  Group[  0]: 2245
  Group[  1]: 2245

[2003/10/31 09:51:33, 4, pid=28744] smbd/reply.c:(278)
  Client requested device type [?????] for share [GLOBALMS]
[2003/10/31 09:51:33, 5, pid=28744] smbd/service.c:(869)
  making a connection to 'normal' service globalms
[2003/10/31 09:51:33, 10, pid=28744] lib/username.c:(504)
  user_in_list: checking user BOEHM in list
[2003/10/31 09:51:33, 10, pid=28744] lib/username.c:(508)
  user_in_list: checking user |BOEHM| against |@IDE_SUPPORT_USERS|
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(312)
  looking for user BOEHM of domain bnrrtp in netgroup IDE_SUPPORT_USERS
[2003/10/31 09:51:33, 5, pid=28744] lib/username.c:(314)
  innetgr is FALSE
[2003/10/31 09:51:33, 2, pid=28744] smbd/service.c:(391)
  user 'BOEHM' (from session setup) not permitted to access this share (globalms)

However, my username 'boehm' is in the netgroup IDE_SUPPORT_USERS. If I add my
username to the valid users list or add a unix group, I can connect.

[2003/10/31 10:00:19, 5, pid=28779] lib/username.c:(312)
  looking for user BOEHM of domain bnrrtp in netgroup IDE_SUPPORT_USERS
[2003/10/31 10:00:19, 5, pid=28779] lib/username.c:(314)
  innetgr is FALSE
[2003/10/31 10:00:19, 10, pid=28779] lib/username.c:(508)
  user_in_list: checking user |BOEHM| against |boehm|
[2003/10/31 10:00:19, 4, pid=28779] rpc_server/srv_srvsvc_nt.c:(217)
  get_share_security: using default secdesc for globalms

Essentially, lookups in netgroups appear to be broken
Comment 1 Jeremy Allison 2003-11-04 10:23:25 UTC
Created attachment 236 [details]
Proposed patch.

Just try lowercase lookups in addition.
Jeremy.
Comment 2 Jeremy Allison 2003-11-04 10:25:01 UTC
Added lowercase lookups also.
Jeremy.
Comment 3 Eric Boehm 2003-11-05 08:04:49 UTC
This change did not fix the bug. There is a problem.

You don't want to change the case of the netgroup/group name.

If you do change the case of the netgroup name, then you need to check all
permutations, i.e.,

user, group
lowercase user, group
user, lowercase group
lowercase user, lowercase group.


However, I think that you should leave the case of the group unchanged.

Here'a potential diff against this patch.I added some debugging code so that I
could see what was happening.

--- lib/username.c.orig Wed Nov  5 10:51:02 2003
+++ lib/username.c      Wed Nov  5 10:57:12 2003
@@ -316,8 +316,9 @@
        DEBUG(5,("innetgr is %s\n", innetgr(ngname, NULL, user, mydomain)
                ? "TRUE" : "FALSE"));
 
-       if (innetgr(ngname, NULL, user, mydomain))
+       if (innetgr(ngname, NULL, user, mydomain)) {
                return (True);
+       } else {
 
        /*
         * Ok, innetgr is case sensitive. Try once more with lowercase
@@ -326,12 +327,16 @@
 
        fstrcpy(lowercase_user, user);
        strlower_m(lowercase_user);
-       fstrcpy(lowercase_ngname, ngname);
-       strlower_m(lowercase_ngname);
 
-       if (innetgr(lowercase_ngname, NULL, lowercase_user, mydomain))
-               return (True);
+               DEBUG(5,("looking for user %s of domain %s in netgroup %s\n",
+                       lowercase_user, mydomain, ngname));
+               DEBUG(5,("innetgr is %s\n",
+                        innetgr(ngname, NULL, lowercase_user, mydomain)
+                        ? "TRUE" : "FALSE"));
 
+               if (innetgr(ngname, NULL, lowercase_user, mydomain)) 
+                       return (True);
+       }
 #endif /* HAVE_NETGROUP */
        return False;
 }

One final note: wouldn't it be better to save the result of the call to innetgr
 from the DEBUG statement rather than make a second identical call?

Comment 4 Gerald (Jerry) Carter (dead mail address) 2004-06-03 13:32:02 UTC
patch applied.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:17:51 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.