[Samba] Problem with large NIS groups - Samba 2.2.8

[Strong, Hugh A.]

Hello from the Military-Industrial Complex!

We're a large defense contractor located in East Hartford, CT, USA.  US
export 
laws make us 'kind of' concerned about who gets in here and what they can 
access.  We've got a problem  with some of the groups that we have in our
NIS 
database.  Everyone who logs into our Sun system is assigned to one of
several 
groups for export-control purposes depending on the type of data they're
allowed 
to see.  This has generated a few very large groups spanning multiple lines
and
sharing the same GID but not the same name.  In general, the sub-groups have
a number at the end of the name to differentiate them.  In total, there are
16,000
users in our passwd map.

The (expurgated) NIS group map for one of these would look a lot like this:

usa:*:21:
usa1:*:21:user1,...,user20
usa2:*:21:user21,...,user40
.....
user235:*:21:   (That's right - over 200 sub-groups)

Now that I'm trying to grant Samba access to some of our on-site foreign
national 
employees and  contractors, this is coming back to haunt us.  For reasons I
won't 
delve into, this requires securing shares via the "valid users" list.  The
code called
by user_in_group_list (2.2.8) matches on group name, not GID, so we would
have 
to put an unmanageable list of groups into every share list and incur large 
overhead.   I've tried to write some additional code to do a lookup by gid,
but this 
involves a sequential search and it turns out to be unacceptably expensive:

struct sys_userlist *get_users_in_group_by_gid(gid_t gid)
{
	struct sys_userlist *list_head = NULL;
	struct group *gptr;

	setgrent();
	while((gptr = getgrent()) != NULL) {
	  if (gid == gptr->gr_gid) {
	    list_head = add_members_to_userlist(list_head, gptr);
	    if (list_head == NULL)
	      return NULL;
	  }
	}
	endgrent();
	return list_head;
}

It all comes down to the fact that matches are not done against an 
instantiated user context with all groups mapped to GIDs. Is there any
way other than using netgroups to make these matches work efficiently? 
Has anyone tried adding some caching logic?

Hugh Strong
CSC Pratt & Whitney Account 
400 Main Street, East Hartford CT 06108, MS 163-17
Engineering Building, 3rd Floor East, J-7  
TechNet: 435-6851  External: (860) 565-6851 Fax: (860) 755-5182
hugh.strong at pw.utc.com