A RID allocator and its consequences

[Volker.Lendecke at SerNet.DE]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> pdb_smbpasswd and pdb_unixsam both use the code in passdb.c
> (pdb_fill_sam_pw()) to construct their SAM_ACCOUNT, and to do uid->sid
> mapping.  In fact, becouse of this, smbpasswd already uses the gid code
> to determine the primary group RID on the fly. 

My thought was that pdb_smbpasswd has to tell get_group_from_gid that
in this particular case we need the algorithmic mapping. The RID
allocator will interfere with the algorithmic mapping for uids for
smbpasswd.

> > What crazy stuff do you mean? unixsam_update_sam_account?
> 
> That certainly sounds familure.

And I'm still looking at the consequences of that hack. I'll tell you
what I think later :-)

> As long as we have never made an implicit mapping between that uid and
> RID, then it's fine. 

That's what I'm trying to hammer out currently.

> One of the ideas with the new SAM stuff is that we always control
> this mapping - it's the autoalgoirthmic stuff that kills us here...

Diggin through the muddy waters of fallback_pdb_* ...

> The only other trick is 'outside modification'.  When people put this
> stuff into LDAP, they often like to modify it directly.  This may be 'a
> bad thing', but it's also somthing we must at least tolerate.  (I
> certainly do it at my site).  Therefore having the max rid stuff in LDAP
> might be benifitial.

Yes. As I said, this was code of about 3 hours. But following Eric
Raymond: Release early, release often.

Volker

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 3700000

iD8DBQE9lAsYZeeQha3jd9gRAox4AJ0eDQw8c1S05kUclULqA1O3WQ34aACdEAht
kPkFtryKEpHxUu+x5u5BBsI=
=nBSk
-----END PGP SIGNATURE-----