The Samba-Bugzilla – Bug 1212
Existing uids/gids severely limit range of available ids
Last modified: 2005-09-29 07:37:04 UTC
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
Deltas off of 3.0.1. Implemented as described in previous patch "could be
minimized by..." paragraph.
not going to apply this patch.