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

[Mathias Dietz]

Hi Michael, Jeremy, 

I'm concerned about the proposal of having fixed ids for well-knowns 
because it has a high potential to break existing customer setups. 
Even though having fixed ids for well-knows sounds appealing, you can not 
guarantee that they do not conflict with existing users on the system.
We use Samba with autorid for many customer installations and it happens 
often that there are existing NFS ids which can not be changed easliy.
A full file system traversal would be needed to replace conflicting ids in 
the acls. Even worse, if conflicting NFSv3 users exists you would have to 
change all the clients as well. In combination with SFU or NIS the 
externally store ids would need to be changed as well.

This will scare some customers and lead to upgrade problems.
Michaels initials proposal sounds more flexible and would not lead to such 
problems. 


Regards

Mathias Dietz 


samba-technical-bounces at lists.samba.org wrote on 30/04/2014 01:26:24:

> From: Michael Adam <obnox at samba.org>
> To: Jeremy Allison <jra at samba.org>
> Cc: Simo <simo at samba.org>, samba-technical 
<samba-technical at lists.samba.org>
> Date: 30/04/2014 01:26
> Subject: Re: Recent changes to autorid (was Re: [SCM] Samba Shared 
> Repository - branch master updated)
> Sent by: samba-technical-bounces at lists.samba.org
> 
> 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
> 
> [attachment "signature.asc" deleted by Mathias Dietz/Germany/IBM]