The report about the problem appearing after updating from RHEL6.1 to 6.2 has not been substantiated.  We don't know when the problem first appeared: it may have been there for a long time.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

It would help if Anaconda would stop including a reference pam_fprintd during an install. The *ONLY* package that should be inserting that line into pamd./system-auth-ac is fprintd-pam. In RHEL6.3+ (only ones I have personal experience) the failure mode of the .so missing is benign but why keep propagating an invalid configuration that was caused by a mis-behaving installer/authconfig default values?

This issue blocks testing of bz1094548. To workaround the issue the pam module needs to be disabled.

As the fprint-pam is included in Base install group I propose this bug also as blocker for RHEL6.7.

After consultation I am removing blocker flag.

I don't quite understand why tcsh can't reset the signal mask when it starts.

Apart from this change in the signal mask, which causes problems to tcsh, what problem does it cause?

There's nothing in pam_fprintd itself that changes the signal mask, it's likely something in glib or dbus.

The breakage of piped commands for tcsh users (which is not a trivial issue) is the only specific effect I have observed in practice.  Note that it is not necessarily tcsh that encounters the problem directly, but commands invoked from the resulting shell.

Note that changing tcsh to reset the signal mask may introduce subtle new issues if existing installations implicitly depend on the current behaviour; signal handling in shells tends to be notoriously brittle.

As a design principle, PAM modules should be as transparent as possible and not introduce side effects such as persistent changes to the process signal mask.  The inclusion or not of a PAM module should not result in unrelated user-visible changes at the application level.  Perhaps pam_fprintd should save the signal mask on entry and restore it at cleanup if the underlying source of the issue cannot easily be found/fixed.

(At this site, the problem has been worked around by removing the fprintd, fprintd-pam and gdm-plugin-fingerprint RPMs, as their functionality is not needed.)

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

Turns out that all this while, glib (in gio/gsocket.c) was responsible for playing with the signal mask.

This problem is fixed in more recent versions of fprintd (from 1.90.1 onwards), which now uses sd-bus instead of dbus-glib.

commit d70f15b5e8fd0f51c882bf4f199036ab503528ef
Author: Bastien Nocera <hadess>
Date:   Tue Jan 14 15:34:06 2020 +0100

    pam: Port to sd-bus
    
    This pam plugin never used GDBus because it transparently uses threads
    which do not work well with a lot of PAM applications. But even settling
    on the "still better to use than plain dbus library" dbus-glib wasn't
    without problems, as any use or initialisation of GIO sockets would
    modify signal handler for signals such as SIGPIPE (see gio/gsocket.c).
    
    Many years later, sd-bus is a more modern alternative to the bare dbus
    library with a better API.
    
    This includes:
    - Removing use of gboolean, guint, g_new0() and many glib string helpers
    - Simplifying debug logging
    - Marking user-facing messages to be translated