Description of problem: Test case failure: https://tcms.engineering.redhat.com/case/169632/?from_plan=18766 Version-Release number of selected component (if applicable): kernel-3.10.0-304.el7.ppc64 PackageKit-1.0.7-4.el7.ppc64 How reproducible: 100% Steps to Reproduce: 1. As root install mc package 2. As non-root user execute: 'pkcon remove gpm-libs' 3. When asked to proceed with deps removal give Yes Actual results: When installation asks: Proceed with changes? [N/y] You can not confirm installation by typing y (it asks over and over in cycle). Expected results: You should confirm installation by typing y and successfully finish installation.
We're using the same unbuffered input code as PolicyKit, polkitagenttextlistener.c -- I'm guessing that experiences the same bug on ppc64? I assume you can't reproduce this on any other architecture?
If termios.h isn't working, this points to a bigger bug with glibc. Reassigning....
Created attachment 1129774 [details] test case
Richard, Awesome test case. That's exactly what we need. The code you posted is BE-unsafe, and ppc64 is a BE target. 44 gint c; 45 c = getc (tty); This stores the value read from the tty in BE to an integer sized object. 46 if (c == '\n') { 47 /* ok, done */ 48 break; 49 } else if (c == EOF) { 50 g_warning ("Got unexpected EOF."); 51 break; 52 } else { 53 g_string_append_len (str, (const gchar *) &c, 1); The '&c' points to start of the integer sized object, which has a value of 0x0 for a character sized object e.g. { &c->[0x0], 0x0, 0x0, 0x59 'Y' }. This makes the code BE-unsafe. To fix this requires a type conversion. You need to do this: gchar gc = (gchar) c; g_string_append_len (str, (const gchar *) &gc, 1); Knowing that `c` won't have a value of EOF, you can safely cast it to a gchar and convert the value (potentially loosing the value of the EOF, but you already checked for it earlier). Then the address of `gc` will point to the valid character value. This is a somewhat classic BE-unsafe thing to do, which works fine on LE targets like x86_64 e.g. { &c->[0x59], 0x0, 0x0, 0x0}. This should also work fine on ppc64le. You should audit your code for BE-unsafe operations like this since ppc64 is not going away any time soon.
Hi Carlos -- thanks for the detailed report, I learned a lesson today. Thanks!
Is this sort of BE-unsafe casting not getting flagged by compiler warnings or coverity checks ?
PolicyKit has the same bug so I filed it here: https://bugzilla.redhat.com/show_bug.cgi?id=1311648
commit 710a9445777793e49160587882860cbb7b43e311 Author: Richard Hughes <richard> Date: Mon May 16 15:27:35 2016 +0100 Make pk_console_get_prompt() big endian safe Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1255079
I could remove and reinstall gpm-libs just with pkcon. Confirmation dialog works.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2425.html