Due to our working environment, we have hard uids and gids scattered throughout a large portion of the possible id ranges. Since all ids in the "idmap uid" and "idmap gid" must be available, this situation severely limits our number of samba users and groups.
Created attachment 454 [details] Check idmap and local files before returning newly allocated ids. This patch contains modifications to source/sam/idmap.c, source/sam/idmap_tdb.c, and source/sam/idmap_ldap.c. The mod to idmap.c provides a new function to determine if a given id was already allocated in idmap, or if the id exists in the /etc/passwd or /etc/group file (using getpwuid and getgrgid, respectively). idmap_allocate_id(), ldap_allocate_id(), and db_allocate_id() were modified such that they will only return ids that do not already exist in the idmap and that are not defined in local files. The modifications to ldap_allocate_id() and db_allocate_id() could be minimized by changing all calls directly to these functions to calls to idmap_allocate_id() instead. However, since the ldap_allocate_id() and db_allocate_id() functions can be called via remote_map and cache_map, the checks were added directly to ldap_allocate_id() and db_allocate_id() to prevent circumventing the fix if idmap_allocate_id() was not used. This patch also modifies the following error. ldap_get_sid_from_id: mapping not found for ... The reason here was that the idmap_id_exists() check is made every time a new uid or gid is created. The message above is a good thing to see in the log in these cases. However, at a level zero debug, these messages could give the impression something is wrong. So, the error was moved from a level 0 debug to a level 1 debug (since it is a serious issue with other cases). Also, idmap_id_exists() will output some level 1 debug to provide some context for the previous message.
Created attachment 455 [details] Variant of first patch, less changes and cleaner Cleaner version of the above, but doesn't perform check on direct calls to ldap_allocate_id() and db_allocate_id(). However, after further code review, it appears these are adequately protected and should only be accessible by idmap.c [specifically its idmap_allocate_id() function]. This patch also prevents a double check that would occur using the first patch when going through idmap_allocate_id(). Deltas off of 3.0.1. Implemented as described in previous patch "could be minimized by..." paragraph.
not going to apply this patch.