refactoring idmap code in smbd

Gerald (Jerry) Carter jerry at samba.org
Thu Jul 10 15:04:35 GMT 2003


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

On Thu, 10 Jul 2003, Andrew Bartlett wrote:

> So when we update a user's full name with user manager, we are happy to
> just leave the nsswtich data stale?  All other winbind users get updated
> - why should users on a Samba PDC be made different?

When you update a username in User Manager, do you current rename 
/etc/passwd entries?

> Likewise, we have the very real issue of account renaming - this happens
> particularly when we have a member server that changes it's name.  
> Currently we are unable to support this - and this deigin makes it
> harder - not easier.

no.  same issue we currently have.  Why is the nt_username field in 
SAM_ACCOUNT not honored consistently.  Maybe I'm missing something here, 
but why won't that work?

> Except the samba we have now is not the Samba we started with - and I
> think that is a very good thing.  We also now have a very clear idmap
> (at lest it was clear), which is SID based.  By putting usernames back
> into the mix, we have the very real risk of inconsistant mappings - as
> some go by sid (NT ACLs) and some go by name (logins) but we never
> double check them both.
> 
> Particularly due to case senstivity and domain qualification issues,
> username based mappings have been phased out of Samba 3.0.  (Until now
> at least...).

If you have left the uid field in SAM_ACCOUNT (on disk), i wouldn't have 
had to use the username :-)  SO really, this would be your fault.
Oh wait, you removed this for idmap.....  The problem here is that 
idmap for local users and an idmap for remote users is really performing 2 
different functions.  The former mappings already exist in 
passdb+/etc/passwd and the latter is really responsible for allocating 
uids/gids.  

That's really the problem I have with idmap.  All it did was take 
local_uid_to_sid() and winbind_uid_to_sid() from 2.2 and merge them into a 
single function.  No reduction in complexity.  Just a cut-n-paste 
job.

So really it was idmap that was duplicating storage when it maintained 
maps for local users.  These maps already existed.  They based on 
usernames now since that is the only common key.  However, adding a uid_t 
field back into SAM_ACCOUNT would solve this (as long as you deal with 
consistency of course).  





cheers, jerry
 ----------------------------------------------------------------------
 Hewlett-Packard            ------------------------- http://www.hp.com
 SAMBA Team                 ---------------------- http://www.samba.org
 GnuPG Key                  ---- http://www.plainjoe.org/gpg_public.asc
 "You can never go home again, Oatman, but I guess you can shop there."  
                            --John Cusack - "Grosse Point Blank" (1997)

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

iD8DBQE/DYCDIR7qMdg1EfYRAqGmAJ0fD5ujbx/eF0mpCfK01MK9HMY35gCfQ2ze
YxztbH6cnkGu/nnn92QrExE=
=R9ZN
-----END PGP SIGNATURE-----




More information about the samba-technical mailing list