[PATCH] New idmap backend that generates id's the way OS X does
John Hixson
john at ixsystems.com
Sat Oct 1 21:03:42 UTC 2016
On Wed, Sep 21, 2016 at 02:16:12PM -0700, Ralph Böhme wrote:
> 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
[root at freenas910 ~]# wbinfo -n 'IX\john'
S-1-5-21-2616990854-1186095534-2674637157-1114 SID_USER (1)
[root at freenas910 ~]# wbinfo -S
S-1-5-21-2616990854-1186095534-2674637157-1114
426797067
[root at freenas910 ~]# wbinfo -U 426797067
S-1-5-21-2616990854-1186095534-2674637157-1114
So is this something anyone is interested in? If not I will leave you
all alone, return to my basement with my stapler and continue on with my
Samba hacking.
- John
>
> 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
More information about the samba-technical
mailing list