#2785 incompatibility between sparkleshare and sss_ssh_knownhostsproxy due to setlocale()

Created 2 years ago by kforner
Modified 8 months ago

cf mail to freeIPA users list, and Alexander Bokovoy asked me to report it as a bug:
*I had problems with sparkleshare on my freeIPA-enrolled workstation, e.g. I got
error messages like this:

19:04:52 | Cmd | QB_resources | git ls-remote --heads --exit-code "ssh://xxxl @yyyy/secure/sparkleshare/resources" master
19:04:52 | Git | projects | (Wed Sep 9 19:04:52:432246 2015) [/usr/bin/sss_ssh_knownhostsproxy] [main] (0x0020): set_locale() failed (5): Input/output error

I went to see the source code of sss_ssh_knownhostsproxy, and it seems that the problem comes from these lines:
c = setlocale(LC_ALL, "");
if (c == NULL) {
return EIO;

According to "man setlocale()", this is perfectly good:

   On startup of the main program, the portable "C" locale is selected as default.  A program may be made portable to all locales by calling:
      setlocale(LC_ALL, "");

For glibc, first (regardless of
category), the environment variable LC_ALL is inspected, next the environment variable with the same name as the category (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC,
LC_TIME) and finally the environment variable LANG. The first existing environment variable is used. If its value is not a valid locale specification, the locale is unchanged, and setlo‐
cale() returns NULL.

In my case, apparently setlocate() returns NULL. I could not reproduce this setlocale() call by myself, event trying to use the environment of the sparkleshare process (which by the way is a mono program).

But I noticed that running sparkleshare as followed fixed the problem:
LC_ALL="en_US.UTF-8" mono "/usr/lib/sparkleshare/SparkleShare.exe"

So I just edited my /etc/default/locale to permanently fix my problem.
Nonetheless, I'd be curious the understand why the setlocale() call fails when sss_ssh_knownhostsproxy is called via git via sparkleshare (via mono).*

Alexander added:
There are multiple cases when your own locale is different from the
remote environment and in cloud images you might not even have
additional locale information available, so when SSH is configured to
pass LC_
variables (like in Fedora or RHEL), they are forced in the
remote shell and the setlocale() result is often NULL. I'm stumbling
with this all the time.*

Fields changed

owner: somebody => mzidek

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.3

Fields changed

rhbz: => todo

There's too many tickets in 1.13 already to be realistically fixed in time, sorry.

Patches welcome on the sssd-devel, but in the meantime, I'm moving the bug to the next milestone.

milestone: SSSD 1.13.3 => SSSD 1.14 beta

Looks like there is an easier reproducer:

0:55 < OgRo> jhrozek: how to reproduce it: login to the server from a macosx with utf-8 encoding; then try ssh-ing outside that box.

milestone: SSSD 1.14 beta => NEEDS_TRIAGE

Fields changed

patch: 0 => 1

Patch available, moving to the next release milestone.

milestone: NEEDS_TRIAGE => SSSD 1.14 alpha


resolution: => fixed
status: new => closed


milestone: SSSD 1.14 alpha => SSSD 1.13.4

8 months ago

Metadata Update from @kforner:
- Issue assigned to mzidek
- Issue set to the milestone: SSSD 1.13.4

Login to comment on this ticket.