#3993 sssd calls internal implementation dependent GLIBC_PRIVATE ABI.
Closed: cloned-to-github 3 years ago by pbrezina. Opened 4 years ago by codonell.

providers/proxy/proxy_init.c

 30 #define NSS_FN_NAME "_nss_%s_%s"
 31 
 32 #define OPT_MAX_CHILDREN_DEFAULT 10
 33 
 34 #define ERROR_INITGR "The '%s' library does not provides the " \
 35                          "_nss_XXX_initgroups_dyn function!\n" \
 36                          "initgroups will be slow as it will require " \
 37                          "full groups enumeration!\n"
 38 #define ERROR_NETGR "The '%s' library does not support netgroups.\n"
 39 #define ERROR_SERV "The '%s' library does not support services.\n"

These are GLIBC_PRIVATE symbols.

You may not call them.

The upstream glibc community reserves the right to remove the symbols at any time.

If we removed the symbols, will it break sssd?


There are still use-cases for using for proxy to files which loads /lib64/libnss_files.so.2

e.g.
https://jhrozek.wordpress.com/2015/07/17/get-rid-of-calling-manually-calling-kinit-with-sssds-help/
https://jhrozek.wordpress.com/2018/03/26/ipa-sudo-rules-for-local-users/

Some cases could be covered by id_provider = files + fixing some bugs there.

But /lib64/libnss_files.so.2 is used also for fix of issue https://pagure.io/SSSD/sssd/issue/3964 (fixed just recently)

...

These are GLIBC_PRIVATE symbols.
You may not call them.
The upstream glibc community reserves the right to remove the symbols at any time.
If we removed the symbols, will it break sssd?

Hi Carlos,

thanks for making us aware of this issue.

Do you mean removing the symbols by e.g. including the nss modules provided by glibc like libnss_files.so.2 in the main libc.so? If yes, is this already planned for some upcoming release?

As Lukas said there are some use cases where we are currently too lazy to open /etc/passwd on our own and parse the content. But this can be changed.

The other use case is the proxy provider. Would __nss_configure_lookup() be still available? If yes we can evaluate if SSSD's proxy provider can use this call. Since it has to call it only once the described memory leak should not be an issue.

bye,
Sumit

Do you mean removing the symbols by e.g. including the nss modules provided by glibc like libnss_files.so.2 in the main libc.so?

Yes. All of the public symbols may be removed, renamed, or changed at will.

If yes, is this already planned for some upcoming release?

There is no planned change, but that's the problem, we would like to be able to make changes to better support the statically linked use case better and we need to know there are no dependencies on these private interfaces.

As Lukas said there are some use cases where we are currently too lazy to open /etc/passwd on our own and parse the content. But this can be changed.
The other use case is the proxy provider. Would __nss_configure_lookup() be still available? If yes we can evaluate if SSSD's proxy provider can use this call. Since it has to call it only once the described memory leak should not be an issue.

Yes, __nss_configure_lookup() is a public symbol and we guarantee it will always be there for runtime usage, but we may deprecate it at some point.

It would be better to understand your need and ensure we have an API that meets that need.

Why are you directly using these private interfaces?

Metadata Update from @pbrezina:
- Issue tagged with: Future milestone

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4965

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @pbrezina:
- Issue close_status updated to: cloned-to-github
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata