Re: winbindd uid and gid range assumptions
On Tue, May 14, 2002 at 08:20:03AM -0400, Mike Gerdts wrote: > On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote: > > Moving over the socket is a very expencive operation, particularly > > compared to a simple if statement. Also, where we know that a uid is > > local, we need to check with code that winbind isn't linked to - the > > passdb backend. > > So in a situation where you have UIDs interspersed between NIS and > domain users, it may be cheaper to check to see if it is local first > followed by winbind. At least this may be better in my situation, as > each of my NFS/Samba servers is already an NIS slave. Even though a UID > lookup may have to talk to nscd and/or ypserv, it is still on the same > machine, thus avoiding network delays. > > Perhaps this would be a place where the plug-in architecture could be > useful as well. Checks could all be relegated to idmap_ops->islocal(). > The default op could be to check the winbind id range. Others that are > willing to or need to pay the price of a socket operation will have the > option of doing so. Presumably islocal() would not just be a straight > BOOL operation. I could imagine it replying True, False, LocalFirst, or > DomainFirst. Sounds like an interesting idea. > > But yes, we need to deal with things like getting the uid from the SFU > > LDAP schema, so this may well change in the future. > > Do you have any relative time frame or rough release number that you are > shooting for? No, its just an idea in my HEAD until I get a chance to look at it, or sombody codes me up a patch :-). > Do you see a plug-in that merges the functionality of the existing idmap > to the architecture present in the VFS, or should I start barking up a > different tree? That seems to be the current plugin arch, but we may move across to a more centralised scheme at some stage. Andrew Bartlett
Re: winbindd uid and gid range assumptions
On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote: > Moving over the socket is a very expencive operation, particularly > compared to a simple if statement. Also, where we know that a uid is > local, we need to check with code that winbind isn't linked to - the > passdb backend. So in a situation where you have UIDs interspersed between NIS and domain users, it may be cheaper to check to see if it is local first followed by winbind. At least this may be better in my situation, as each of my NFS/Samba servers is already an NIS slave. Even though a UID lookup may have to talk to nscd and/or ypserv, it is still on the same machine, thus avoiding network delays. Perhaps this would be a place where the plug-in architecture could be useful as well. Checks could all be relegated to idmap_ops->islocal(). The default op could be to check the winbind id range. Others that are willing to or need to pay the price of a socket operation will have the option of doing so. Presumably islocal() would not just be a straight BOOL operation. I could imagine it replying True, False, LocalFirst, or DomainFirst. > But yes, we need to deal with things like getting the uid from the SFU > LDAP schema, so this may well change in the future. Do you have any relative time frame or rough release number that you are shooting for? Do you see a plug-in that merges the functionality of the existing idmap to the architecture present in the VFS, or should I start barking up a different tree? Mike
Re: winbindd uid and gid range assumptions
Mike Gerdts wrote: > > It seems as though there was an assumption that users of winbindd would > have switched entirely to NT domain authentication or that they would > have distinct range of UIDs/GIDs for /etc/passwd (or NIS) and NT domain. > Is there any good reason to not just let get_id_from_sid() in > nsswitch/winbindd_idmap.c do all the checking? It seems as though the > optimization achieved by the multitude of checks is minimal and greatly > reduces the chances integration possibilities between winbindd and > traditional unix authentication. Moving over the socket is a very expencive operation, particularly compared to a simple if statement. Also, where we know that a uid is local, we need to check with code that winbind isn't linked to - the passdb backend. But yes, we need to deal with things like getting the uid from the SFU LDAP schema, so this may well change in the future. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
winbindd uid and gid range assumptions
It seems as though there was an assumption that users of winbindd would
have switched entirely to NT domain authentication or that they would
have distinct range of UIDs/GIDs for /etc/passwd (or NIS) and NT domain.
The most obvious sign of this is the peppering of statements like the
following throughout various files:
/* Bug out if the gid isn't in the winbind range */
if ((state->request.data.gid < server_state.gid_low) ||
(state->request.data.gid > server_state.gid_high)) {
return WINBINDD_ERROR;
}
Also, smbd/uid.c does a similar check before calling
winbind_[ug]id_to_sid():
if (lp_winbind_uid(&low, &high) && uid >= low && uid <= high) {
if (winbind_uid_to_sid(psid, uid)) {
DEBUG(10,("uid_to_sid: winbindd %u -> %s\n",
(unsigned int)uid, sid_to_string(sid, psid)));
return psid;
}
}
Is there any good reason to not just let get_id_from_sid() in
nsswitch/winbindd_idmap.c do all the checking? It seems as though the
optimization achieved by the multitude of checks is minimal and greatly
reduces the chances integration possibilities between winbindd and
traditional unix authentication.
Mike
