Bug 827188 - fprintd-pam module causes SIGPIPE to be ignored by children
fprintd-pam module causes SIGPIPE to be ignored by children
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fprintd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Bastien Nocera
Desktop QE
: TestBlocker
Depends On:
  Show dependency treegraph
Reported: 2012-05-31 16:40 EDT by Dan Astoorian
Modified: 2017-12-06 06:02 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-06 06:02:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Astoorian 2012-05-31 16:40:24 EDT
Description of problem:
If the fprintd-pam module is in use, it causes the PAM client (e.g., /bin/su) to ignore SIGPIPE.  Child processes then inherit the SIG_IGN disposition for the signal.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. 'su' to a user whose shell is /bin/tcsh (not /bin/sh or /bin/bash); OR, log in from the text console.  (In general, log in through a method which uses /etc/pam.d/system-auth-ac.)
2. cat /dev/zero | true
Actual results:
cat: write error: Broken pipe

Expected results:
No output, with cat being terminated with SIGPIPE

Additional info:
Note that /bin/bash resets the signal disposition for SIGPIPE during initialization, so trying this with a user whose shell is /bin/sh or /bin/bash masks the problem.

Commenting out the "auth sufficient pam_fprintd.so" line in /etc/pam.d/system-auth-ac makes the symptom go away, as does removing the fprintd and fprintd-pam packages, which is how the problem was isolated to fprintd-pam.

("grep SigIgn /proc/$$/status" may also be used to observe the change in the ignored signals mask; instead of 0000000000384004, the mask appears as 0000000000385004.)

We think the symptom appeared after updating from RHEL6.1 to RHEL6.2, but we are not 100% sure of that.  I suspect that the underlying cause of the bug might be in some underlying library rather than in fprintd-pam itself, but I have not been successful in identifying the component that changed to introduct the problem.
Comment 2 Dan Astoorian 2012-06-01 10:57:53 EDT
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.
Comment 6 RHEL Product and Program Management 2012-07-10 04:46:11 EDT
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.
Comment 7 RHEL Product and Program Management 2012-07-10 19:13:44 EDT
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.
Comment 8 RHEL Product and Program Management 2012-09-07 01:37:40 EDT
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.
Comment 9 matthew patton 2013-03-11 13:10:47 EDT
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?
Comment 10 Dalibor Pospíšil 2015-03-09 12:01:06 EDT
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.
Comment 11 Dalibor Pospíšil 2015-03-09 12:38:17 EDT
After consultation I am removing blocker flag.
Comment 12 Bastien Nocera 2015-03-25 17:17:27 EDT
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.
Comment 13 Dan Astoorian 2015-04-06 10:01:56 EDT
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.)
Comment 14 Jan Kurik 2017-12-06 06:02:43 EST
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:


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:


Note You need to log in before you can comment on or make changes to this bug.