Bugzilla #109

[Andrew Bartlett]

On Tue, 2003-07-01 at 15:44, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Andrew B., Simo, or someone,
> 
> 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.

Given the current completely broken state we find ourselves in, I cannot
argue against this.  Thanks for chasing this down.

That said, there are a few points to note, and a few possible ways to
solve this:

Firstly, we have committed the first crime in database design - we have
stored the same data in two different formats, and found that even when
we fix the 'add' code, that people can change their primary group.

We have two options:  We can move back to the way Samba 2.2/early 3.0
did it - read the user's unix GID, and pass this down to the setegid()
function.  This leaves the RID and GID separate, as we had before.

The other option is as you suggest - map the PrimaryGroupSID from the
user's unix gid.  This has a few issues:
 - Firstly, under unix, the primary GID is often a user-private group
   (This may not be what we want the NT sid to represent)
 - We may not have ready access to the user's unix GID.
 - We might have performance issues with gaining that GID.

The performance issue isn't all hand-waving - the 'ldap trust ids'
parameter was added for exactly this issue - we made GetPwnam() calls in
the past that killed performance for 'Stefan Metzmacher'.  

The problem is making getpw* calls for each entry - as there can be a
lot of calls for the enumeration.  We should take care to use direct
ldap calls for the conversion, for performance.

Naturally, this can't work for the mythical 'non unix accounts'/'no unix
accounts', where we are trying to do the reverse mapping.  However,
until we get the full group database etc this is a non-issue.

We had also been working to remove nss calls from the passdb - but the
same applies to groupdb.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030701/51a4de64/attachment.bin