refactoring idmap code in smbd

[Gerald (Jerry) Carter]

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

On Wed, 9 Jul 2003, Esh, Andrew wrote:

> Have you considered UID collisions other than UID 0? 

The check for uid == 0 was simply to catch unitiialzation bugs.

> Right now, windbindd simply has a range of IDs it can assign, which is
> configurable. It is assumed the admin has given winbindd authority to
> use all of the IDs in that range, and they have chosen the range so as
> not to collide with other ID assignment authorities. Such a range may
> not always be enough, and the assumption is usually wasteful of UID
> numbers.

Given a 32 bit uid space, have you come across this being 
a problem in practice?

> For example, using a hash function for the potential Windows users from one
> domain, converting their RIDs to UIDs, requires the entire Unix user ID
> space be allocated to winbindd's use. I realize that there probably won't be
> that many users in one domain, but then there are trusted domains. What
> happens from an administrative standpoint when the range runs out?
> 
> The problem is this: The inclusion of UIDs from /etc/passwd, NIS, and
> Trusted Domains leads to the need for a complex UID assignment function. Is
> that going to be scriptable, because there doesn't appear to be a generic
> solution to the problem.

Write your own IDmap backend and implement idmap_allocate_id() 
however you want.  Very flexible. :-)





cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/DGS5IR7qMdg1EfYRAn2YAKDPlC3jGVQK8nc/BQuAS+8flnm4pQCgvDCG
37+xkGU8/pWM0jpXXMIGv6k=
=jjAG
-----END PGP SIGNATURE-----