The Samba-Bugzilla – Bug 4850
[PATCH] Provide getgroupmembership for FreeBSD NSS
Last modified: 2014-10-30 08:32:19 UTC
The attached patch provides a getgroupmembership function through the nss dispatching mechanism. Support for getgroupmembership in FreeBSD is not yet included, but a working patch is finished .
The getgroupmembership function interface in FreeBSD is identical to NetBSD's. The attached patches therefore puts a verbatim copy of the getgroupmembership function from winbind_nss_netbsd.c in winbind_nss_freebsd.c, no code is changed.
This should probably be changed in some way, to remove the code duplication again. I'm not exactly sure how and my skills with the makefile system aren't too good either, so tips are appreciated. I would propose an extra winbind_nss_bsd.c that would contain just this function and be shared between FreeBSD and NetBSD?
Created attachment 2848 [details]
Patch adding getgroupmembership to nss_winbind
Hmm, I should probably say a little something about what the patch actually _does_ :-)
Currently, FreeBSD answers getgrouplist calls ("in what groups is this or that user?") by iterating all groups and all users in them to see in which groups a user is. With the getgroupmembership nss function, the actual query can be dispatched to winbind directly.
This has two advantages. Firstly, there is a huge performance gain for sites having lots of groups and users. Secondly, it makes nested groups behave properly. The code path used by getgroupmembership is better maintained and handles nested groups in the right way, as opposed to the getgrent call which doesn't.
Lastly, the inclusion of this patch is not dependent on the inclusion of getgroupmembership support in FreeBSD. In winbind, this just adds another function call which remains unused. In FreeBSD, a fallback mechanism is provided that uses the old getgrent iterating method if getgroupmembership is not available in a given backend.
Timur, Want to take a look at this and give an ACK or not?
(In reply to comment #3)
> Timur, Want to take a look at this and give an ACK or not?
Thanks, Jerry, I'll take a look into this patch.
On the topic, is it possible for me to be added automatically to Cc: in case the hosting OS for the bug report is FreeBSD? That would save me scaning bugzilla all the time :)
The getgroupmembership interface in FreeBSD has been committed to HEAD and it should become available soon (but probably not yet in the upcoming 7.0 release).
Any progress on applying this patch?
(In reply to comment #5)
> The getgroupmembership interface in FreeBSD has been committed to HEAD and it
> should become available soon (but probably not yet in the upcoming 7.0
> Any progress on applying this patch?
Well, after 5 years... :)
The patch itself doesn't match the ndispatch() API, but I've made my own to address this.
What confuses me is that getgroupmembership() function never appeared in the libc, except a ndispatch hook for it appearing there. Not sure, was that intended or full transition just never happened..
I've stopped using FreeBSD, so I no longer have an active interest in this patch.
As for your question, it occurs to me that the getgroupmembership function was something internal. Looking on linux, I find the getgrouplist() libc function, which, IIRC, is essentially the same function but with a slightly different interface. Also, I think that on Linux, getgrouplist was implemented using initgroups_dyn in the NSS backends, but on *BSD, it was implemented using getgroupmembership (falling back to scanning all groups and their members in both cases).
Does that help?
(In reply to comment #7)
> I've stopped using FreeBSD, so I no longer have an active interest in this
> Does that help?
Yes, thanks, that corresponds to my findings. Initially I was expecting to see:
in FreeBSD, but as you say, getgrouplist() is almost the same.
Thanks for clarification and out of curiosity - why did you stop using FreeBSD? PM, if any :)
Really good stuff, this patch, thanks a lot!
Virtually no login delays anymore. :-)
Please, take a look at:
this will be fixed in 4.2 and in the upcoming 4.0.x and 4.1.x releases
*** This bug has been marked as a duplicate of bug 10835 ***