On Tue, Feb 23, 2016 at 09:39:34AM +0100, Lukas Slebodnik wrote:
> On (22/02/16 10:44), Jakub Hrozek wrote:
> >On Mon, Feb 22, 2016 at 10:35:21AM +0100, Lukas Slebodnik wrote:
> >> On (22/02/16 10:28), Jakub Hrozek wrote:
> >> >On Mon, Feb 22, 2016 at 10:19:31AM +0100, Lukas Slebodnik wrote:
> >> >> On (22/02/16 10:01), Jakub Hrozek wrote:
> >> >> >Hi,
> >> >> >
> >> >> >during my work on pam_hbac I ran into some issues in libipa_hbac that I
> >> >> >would like to fix. And before doing the work I wanted to check if
> >> >> >anyone
> >> >> >is opposed to these changes.
> >> >> >
> >> >> >I would like to:
> >> >> > 1) Stop using C99 in libipa_hbac. pam_hbac can run on old and/or
> >> >> > strange platforms that don't support C99 compilers.
> >> >> >
> >> >> > 2) Stop using sss_utf8_case_eq unconditionally and rather use an
> >> >> > externally-provided function, a bit like we already set the debug
> >> >> > function. I was thinking even about creating hbac_init() that
> >> >> > would accept these functions and return a context which would then
> >> >> > be passed to other libipa_hbac functions, but this would be an API
> >> >> > break. Alternatively, we could just use a function setter, I just
> >> >> > think
> >> >> > the context might be clearer..and IIRC the C libipa_hbac API is
> >> >> > used
> >> >> > only by the python bindings at the moment.
> >> >> >
> >> >> what about ifdef?
> >> >
> >> >How would I solve this with ifdef? I mean, the consumer of the library
> >> >has to provide the UTF8 case-matching function one way or another.
> >> The same way as in src/util/sss_utf8.c.
> >> or which (external) function would you like to use on other platforms?
> >
> >I think this is fine for whoever is implementing the functions, but I'm
> >not sure I like ifdefs in the libipa_hbac itself..
> >
> >If we don't want to change the API, what about adding
> >"hbac_set_utf8_case_eq_fn()" that SSSD would call with
> >sss_utf8_case_eq() and pam_hbac would call it with something like
> >ph_utf8_case_eq() ?
> >
> >(I didn't like the global function pointer inside libipa_hbac, that's
> >why the context seemed nicer to me..)
>
> src/util/sss_utf8.c is part of libipa_hbac
thanks, I missed that.
>
> libipa_hbac_la_SOURCES = \
> src/providers/ipa/hbac_evaluator.c \
> src/util/sss_utf8.c
>
> Function is not exported and therefore not visible in objdump output
> sh$ objdump -T /usr/lib64/libipa_hbac.so.0 | grep sss
> sh$ echo $?
> 1
>
> But you can see that library depends on libglib
> sh$ objdump -p /usr/lib64/libipa_hbac.so.0 | grep NEEDED
> NEEDED libglib-2.0.so.0
> NEEDED libc.so.6
>
> IMHO it's better if utf8 string comparision is part of library.
>
> Could you explain benefit of your approach?
There is none -- I thought for some reason that the hbac evaluator depended
on libsss_util, but you're right that we actually use:
825 libipa_hbac_la_SOURCES = \
826 src/providers/ipa/hbac_evaluator.c \
827 src/util/sss_utf8.c
Which makes sense for pam_hbac, too, so I'm just going to borrow
sss_utf8 as well in pam_hbac.
Sorry about the confusion.
_______________________________________________
sssd-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
