[PATCH] New idmap backend that generates id's the way OS X does

[John Hixson]

On Tue, Sep 20, 2016 at 09:54:20AM -0700, Ralph Böhme wrote:
> Hi John
> 
> On Tue, Sep 20, 2016 at 07:13:51AM -0700, John Hixson wrote:
> > I wrote this for FreeNAS and want to know if you guys can use it?
> 
> Does this actually work at all? To me it looks like in
> idmap_fruit_unixids_to_sids() you're missing to prime the synthesized
> SIDs in the struct id_map array.

Yes, it actually works. Can you elaborate more on this?

> 
> I also thought about adding such an idmap module before but I always
> choke at the point where I realized that this can cause collisions and
> it doesn't support idmap number ranges, so it can generate mappings
> with xids from other idmap backends.

When I set out to do this, I found an article stating that the current
OS X scheme indeed can have collisions. Is it a feature or a bug that
this can reproduce the same behavior? ;-)

> 
> What do you do for two sids
> 
> 01020304-a390-44b3-a658-1e0623d09332
> 01020304-90ed-4dd2-9cdc-c21b21aace2d
> 
> Or
> 
> 00000000-90ed-4dd2-9cdc-c21b21aace2d


Eww. This is nasty indeed. Perhaps user id 0 can be a special case? I
wrote this code for certain people who use FreeNAS + Active Directory and
use SMB and AFP together with NFSv4 ACL's on the SMB shares and want those
to work on AFP as well. This code does indeed work and has been tested. Any
pointers are more than welcome. I just wanted to know if it would be
useful to the Samba project. I'd be glad to do any additional work to
make it worthy ;-) (including writing a man page!).

- John

> 
> This user will be happy to be running as the root user.
> 
> And afaict
> 
>     idmap config * : backend = tdb
>     idmap config * : range = 10000-19999
>     idmap config FOO : backend = fruit
>     idmap config FOO : range = 20000-4294967295
> 
> won't really work as it should as idmap_fruit doesn't work this way,
> but we need an allocating idmap backend as the default backend.
> 
> -slow