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

[Ralph Böhme]

On Wed, Sep 21, 2016 at 04:01:27AM -0700, John Hixson wrote:
> 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?

well, maybe I'm to stupid due to attending SDC and still recovering
from jetlag (and Bennigan's), but with the patchset you posted (infact
just applying patch 3/3) this is what I get:

slow at member1:~/samba/master$ sudo ./bin/wbinfo -S S-1-5-21-3152989960-574718769-2188965058-500
2002901632

slow at member1:~/samba/master$ sudo ./bin/wbinfo -U 2002901632
failed to call wbcUidToSid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert uid 2002901632 to sid

Log:

[2016/09/21 13:15:46.668334,  1, pid=12118, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:450(ndr_print_function_debug)
       wbint_UnixIDs2Sids: struct wbint_UnixIDs2Sids
          in: struct wbint_UnixIDs2Sids
              domain_name              : *
                  domain_name              : 'hillhouse'
              num_ids                  : 0x00000001 (1)
              xids: ARRAY(1)
                  xids: struct unixid
                      id                       : 0x7761da80 (2002901632)
                      type                     : ID_TYPE_UID (1)
[2016/09/21 13:15:46.668370, 10, pid=12118, effective(0, 0), real(0, 0), class=idmap] ../source3/winbindd/idmap.c:509(idmap_find_domain)
  idmap_find_domain called for domain 'hillhouse'
[2016/09/21 13:15:46.668382,  7, pid=12118, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ads.c:62(ads_cached_connection_reuse)
  Current tickets expire in 35887 seconds (at 1474524833, time is now 1474488946)
[2016/09/21 13:15:46.668392,  0, pid=12118, effective(0, 0), real(0, 0), class=idmap] ../source3/winbindd/idmap_fruit.c:216(idmap_fruit_unixids_to_sids)
  idmap_fruit_unixids_to_sids: SID [S-0-0]
[2016/09/21 13:15:46.669477,  5, pid=12118, effective(0, 0), real(0, 0)] ../source3/libads/ldap_utils.c:81(ads_do_search_retry_internal)
  Search for (|(&(|(sAMAccountType=805306368)(sAMAccountType=805306369)(sAMAccountType=805306370))(|(objectSid=S-0-0)))) in <dc=HILLHOUSE,dc=SITE> gave 0 replies
[2016/09/21 13:15:46.669503, 10, pid=12118, effective(0, 0), real(0, 0), class=idmap] ../source3/winbindd/idmap_fruit.c:282(idmap_fruit_unixids_to_sids)
  No IDs found

I imagine the filter should be built from the synthesized objectGUID,
not the objectSid? Wrong patchset posted?

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

Do you have a link to this article?

> Is it a feature or a bug that this can reproduce the same behavior?
> ;-)

The real problem I see comes from the fact that on a client the risk
of a collision will be much lower compared to a server.

This has security implications, users with colliding ids will be able
to access each others file. How do you deal with that?

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

What about all other local ids from /etc/passwd? What about not being
able to map well-known, builtin and local SAM?

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

Well, as you know, on the server they work anyway, it's just you wont
be able to see them on the client if ids don't match for AFP clients,
right? The thing is, if your AFP clients enter the mode where they
think ids match and they start fetching ACLs and requisting extended
permission checks via FPAccess, you take a performance hit. At least
that was my take away when I implemented the ACL stuff in Netatalk and
I saw the clients doing FPAccess checks like crazy. I would just stay
away from it these days. :)

Cheerio!
-slow