Recent changes to autorid (was Re: [SCM] Samba Shared Repository - branch master updated)

[Michael Adam]

On 2014-04-29 at 10:14 -0700, Jeremy Allison wrote:
> On Tue, Apr 29, 2014 at 10:54:29AM +0200, Michael Adam wrote:
> > > 
> > Do I get it right that you don't mean to carve out
> > a range for the well knowns in the autorid setting,
> > but globally in samba/winbind, i.e. have a universal
> > configuration of the well-knowns that is independent
> > of any id mapping setup?
> 
> Yes. That's what "Wellknown" means :-).
> 
> > What do you intend to remap? The IDs that have been
> > configured previously? This is difficult, since they
> > have probably already made it into the file system
> > ownerships and acls.
> > 
> > Next thing to consider is what to do with those
> > setups where the well-knowns have been created
> > perviously in the id mapping range. You also need
> > to traverse the File system and potentially change
> > acls before you can run with the new code, so similar
> > problem here..
> 
> We could provide documentation on what to
> do in this case. But refusing to start is
> a strong statement that this needs fixing
> before we'll cope :-).

While I really would like this, I have until today
refrained from implementing it, since I thought we
want to keep existing setups working...

Just documenting that something is not working any
more and explaining that a user may have to
traverse his petabytes (possibly) of data and change
the acls before he can continue using samba is not
precisely nice...

If we want to go that way, I think we would need to:

1. Make the new mapping turnable-off by a config
   setting in the first release.
2. Maybe even make it turned off in the first
   release and change the default to turned
   on in the second one.
3. Deprecate the setting, maybe in a next release.
4. Remove the setting and the legacy code in a
   later release.

Doing all that in one release would really be radical.

> > I don't think it is very dramatic, but instead
> > a very desirable and natural thing. But unfortunately
> > I currently see too many devils in the details to
> > get upgrades and conflicting configs propoerly supported.
> > 
> > If we were to introduce the deterministic well-known
> > mappings, this would be very simple indeed.
> 
> Wellknown == Fixed for all time in all configs.
> 
> That's what Microsoft did for ID's they know
> they have to have. We need to do the same IMHO.
> 
> We screwed ourselves up by being too flexible
> here I think. Fix it finally for 4.2 ?

Well, as stated above, I am not sure we should or can
do in one release, but rather in several steps.

While we are at it, I'd like to rip the ID allocator
out of id-mapping (needed for group mapping and,
for what it's worth, ldapsam-editposix, which is
probably not so relevant any more with AD available).

What would be a good strategy?
For the end result I can imagine:

1. Define a minimum number IDMAP_LOW that can be occupied
   by an idmap range, say 100,000 or 1,000,000.

   Fail winbind start when there is an idmap range
   that goes below that.

2. Define fixed (hard coded) mutually disjoint ranges < IDMAP_LOW :
   a) a range for the wellknowns
   b) a range for the builtins
   c) a range as unix-id-pool (for group mapping, etc)

3. Hard code mappings for the builtins and wellknowns
   in the above ranges.
   This can eventually allow us to remove quite a few special
   cases from idmap and passdb code.

4. Provide a uid/gid counter for the alloc range.
   and remove allocate_id from the winbindd API.


One additional plan I have is this:

Add a mode to samba that lets all SID<->xID mappings be done by winbindd,
i.e. don't go through passdb any more for the own sam.

For builtin this can be done already done by setting
"tdbsam:map builtin == false" (and "passd backend = tdbsam" of
course.
See "git log e17bc56^..ad86e2a" for what we did last year.
This can serve as a model for the sam.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140430/64f948d6/attachment.pgp>