Bug#487104: nis: map values containing non-ascii characters vanish
reassign 487104 nis
thanks
On Fri, Aug 15, 2008 at 04:15:34PM +0100, Mark Brown wrote:
> severity 487104 important
> thanks
>
> On Fri, Aug 15, 2008 at 05:08:37PM +0200, Aurelien Jarno wrote:
>
> > No as Jonathan just confirmed, this actually does not prevents login, this
> > only prevents the entries from being displayed with ypcat.
>
> Downgrading the bug, then - as I said, the original justification for
> the bug being RC was that logins were not possible.
>
> > In short the glibc correctly fetch the account entries via the NSS module,
> > but then ypcat fails to print them.
>
> What makes you belive that ypcat is using NSS for this? As I said in my
> previous mail it is using the yp_all() API with the callback routine I
> posted.
>
Sorry, I hadn't read the nis code before. You are right that yp_all() is
used by ypcat, however I am now convinced that the problem is in nis and
not in glibc:
For each entry, yp_all() calls the callback with the string and the
number of bytes in the string. ypcat uses this string and the number of
bytes with fprintf(), while fprintf actually takes the length of the
string, which can be different in a non-C locale. Moreover ypcat
explicitly switches the locale from C to the environment locale at the
beginning of main().
I don't expect ypcat to print a correct string when the encoding of the
NIS server and the locale of the client do not match, but at least it
should not drop the line, and either print the line with broken
characters or print an error message.
Aurélien
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: