Bug 1212 - Existing uids/gids severely limit range of available ids
Summary: Existing uids/gids severely limit range of available ids
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.11
Hardware: All All
: P2 major
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Reported: 2004-03-24 15:11 UTC by John Klinger
Modified: 2005-09-29 07:37 UTC (History)
2 users (show)

See Also:

Check idmap and local files before returning newly allocated ids. (11.08 KB, patch)
2004-03-24 15:45 UTC, John Klinger
no flags Details
Variant of first patch, less changes and cleaner (4.09 KB, patch)
2004-03-24 19:29 UTC, John Klinger
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Klinger 2004-03-24 15:11:52 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.
Comment 1 John Klinger 2004-03-24 15:45:23 UTC
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.
Comment 2 John Klinger 2004-03-24 19:29:35 UTC
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.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-09-29 07:37:04 UTC
not going to apply this patch.