[Samba] A few questions and propostions on the samba architecture

Andrew Bartlett abartlet at samba.org
Fri Jul 13 08:49:58 UTC 2018


On Fri, 2018-07-13 at 09:46 +0100, Rowland Penny wrote:
> On Fri, 13 Jul 2018 20:25:47 +1200
> Andrew Bartlett via samba <samba at lists.samba.org> wrote:
> 
> > On Fri, 2018-07-13 at 09:36 +0200, Anton Engelhardt via samba wrote:
> > > Due to a few problems I encountered I had a tiny look at the samba
> > > code and gut a few questions, statements and propositions. Please
> > > by all means, correct me if I got something wrong.
> > > 
> > >  1. besides filestore for shares and config files samba uses ldb as
> > > an exclusive storage backend
> > >      1. LDB supports TDB, LDAP and SQLITE3 backend
> > >      2. Samba hard codes to TDB files like "sam.ldb"
> > >  2. ldap does not support any server side actions
> > >      1. Not possible to implement "on create class user
> > >         uidNumber=get_next_free_uid()"
> > >      2. Only possible to define required/optional attributes
> > >      3. ldap service is provided trough ldb-ldap -> tdb
> > > 
> > > I don't know if it is a good idea, but when using something like
> > > sqlite3 it would be possible to use "CREATE TRIGGER", to perform
> > > some automation magic on server side, like giving out uidNumber and
> > > gidNumber.
> > > 
> > > Or even use "CREATE VIEW" with "CREATE TRIGGER" to implement fancy
> > > stuff like server side transparent password token validation.
> > > 
> > > Depending on my undarstanding of the current architecture and the
> > > state of the ldb sqlite backend this would seem like the easiest
> > > approach, correct me if I'm too far off.
> > 
> > Using ldb_sqlite wouldn't help, as we don't use it in a smart way, it
> > was added (and then left unmaintained, we really should remove it) in
> > the hope of getting transaction support, but instead that was gained
> > via tdb.
> > 
> > The uidNumber and gidNumber changes you desire are reasonable, and we
> > could do those in the samldb module or similar.  We haven't done so
> > because:
> >  - at the time we were trying to match Windows AD behaviour exactly.  
> >  - the allocation needs to be stateless or manage the free id pool
> > like the RID pool.
> > 
> > (Because we need to ensure that two users created at the same time on
> > different servers don't overlap uids)
> 
> Yes, but we still could have this problem if ADUC is installed on two
> Windows PC's and two people create a user at the same time. Not that we
> would have this problem on Win10 though.
>  
> > 
> > My preference is to have these modules use the same RID+offset
> > algorithm that sssd uses, and leverage the RID as a unique value.
> 
> Yes the RID would be unique, but the offset might not be, so you
> could get collisions.

The offset is per-domain, stored in the trustPosixOffset and by default
calculated using the same hash as sssd uses.  It is possible two
domains that were not trusted will become trusted and have enough users
to clash in the 32 bit number space, but as a famous Australian once
said 'such is life'.

> > 
> > The key would be to make this relatively compatible with the settings
> > used in winbindd on the file server, so if that RID base were
> > inappropriate another could be chosen via idmap_rid.
> 
> How about this, dump EVERY winbind backend except 'rid' and then obtain
> the lower range at provision time.

Don't worry.  Every new Samba team member makes it their mission to
finally solve IDMAP.  Welcome Rowland!

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




More information about the samba mailing list