refactoring idmap code in smbd

[Steve Langasek]

On Wed, Jul 09, 2003 at 05:06:11PM +0000, Jeremy Allison wrote:

> > The new code has been checked in.  Please see 
> > docs/README.idmap-and-winbind-changes in CVS for details.
> > I'm sure there will be a lot of discussion on this.

> Adding a password and group database source to winbindd allows
> easy migration of existing NT SAM databases (all the new users/
> sids get auto created by winbindd and are now seen by the rest
> of the system), and also the creation of machine accounts without
> having to have them in /etc/passwd (winbindd creates the entries
> in its own db).

> smbd is greatly simplified as it can always assume that any account is
> really a unix account and a sid mapping exists. When we need a
> new account we use the 'create script' if the admin defined one,
> otherwise the new capability of winbindd to create a user or
> group account if the admin permits it.

Now, the README says:

> 3) New functions have been added to winbindd to emulate the 'add user script'
>    family of smbd functions without requiring that external scripts
>    be defined.  This functionality is controlled by the 'winbind enable local 
>    accounts' smb.conf parameter (enabled by default).
   
>    However, this account management functionality is only supported in
>    a local tdb (winbindd_idmap.tdb).  If these new UNIX accounts must be 
>    shared among multiple Samba servers (such as a PDC and BDCs), it
>    will be necessary to define your own 'add user script', et. al.
>    programs that place the accounts/groups in some form of directory
>    such as NIS or LDAP.  This requirement was deemed beyond the scope
>    of winbind's account management functions.  Solutions for distributing 
>    UNIX system information have been deployed and tested for many years.
>    We saw no need to reinvent the wheel.

So assuming that Samba is configured to disallow creation of accounts
within winbind (in the case of an LDAP-using site that needs consistent
ids, for example), does this mean that there will not be an actual idmap
stored anywhere -- that Samba will simply run the create user script,
which allocates an available uid, and assigns a DOM\user name to that
uid?  This is attractive, but dangerous; not only would it depend on
being able to resolve an SID to a name before mapping to a uid[1], there's
also the issue of username reuse in a foreign domain -- NT is careful to
never reuse an SID after the user it belongs to is deleted, but a
name-based map would let a user inherit any Unix filesystem access
belonging to the predecessor.

Or maybe my understanding is flawed here.  Is there something that will
store a direct SID-uid map, in the case of a non-winbind managed
account?

-- 
Steve Langasek
postmodern programmer

[1] Caching can alleviate some of the problems here, but it wouldn't
address the case of an SID that doesn't correspond to a trusted domain
-- it still would need to be mapped if ACLs are to be kept intact!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20030709/2750bb79/attachment.bin