refactoring idmap code in smbd

[Steve Langasek]

On Thu, Jul 10, 2003 at 09:07:33AM -0500, Gerald (Jerry) Carter wrote:

> > 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

> you have to have a uid before you can get a SID.  See samr_create_user()

In the case of a foreign SID, the SID already exists.  I'm talking
about an ACL someone's trying to set, that references an SID we can't
resolve.

It's specifically been said that winbind will not be able to use any
backends other than tdb, and that anyone needing consistent uids across
multiple systems will have to use "add user script".  Well, how can I
use add user script for a foreign SID whose name I don't know?

> > also the issue of username reuse in a foreign domain

> samr_create_user() if for your get_global_sam_name() so there 
> is no conflict here.  On a real domain member or DC, winbindd_acct.c 
> is only used for local users.  I think there's one small bug I need 
> to track down today, but that is how it should work.

I don't understand, then.  If winbindd_acct.c is only used for local
users, how are security descriptors for remote SIDs going to be mapped
to filesystem ACLs?

> > -- 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.

> If you delete a user from /etc/passwd and readd a new user 
> with the same UID, whose fault is that?  Samba is not Windows 
> so we have certain constraints to work within.  Suppose we create
> a new user with a unique sid but the same username as a user in 
> /etc/passwd.   Whose fault is that?  My conjecture is that it is 
> the admins.  

It's the admin's fault for assuming that Samba will work like an NT
server in this regard?

This particular constraint is inherent to a username-based map.  It was
not present in the previous idmap design.

> But lest you be worried about.  an rpc call to delete a user 
> will also be able to delete the user from winbindd's account tdb.  
> I just have to code up the winbindd_delete_user() and 
> winbindd_delete_group() calls today.

But we can't *use* winbindd's account tdb.  We need LDAP.  I've read
preceding comments as saying there will be no idmap solution that uses
LDAP as a backend.  Using a local tdb for idmapping is not a viable
solution in our environment; if no consistent idmap is possible, we're
better off not allowing the use of idmap at all.

Besides which, why would the Samba server receive a delete user rpc call
for a user that's part of a remote trusted domain?

-- 
Steve Langasek
postmodern programmer
-------------- 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/20030710/b56c39a1/attachment.bin