Bug 827188
| Summary: | fprintd-pam module causes SIGPIPE to be ignored by children | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Dan Astoorian <djast> |
| Component: | fprintd | Assignee: | Bastien Nocera <bnocera> |
| Status: | CLOSED WONTFIX | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | bberg, dapospis, djast, dkopecek, pattonme, tpelka |
| Target Milestone: | rc | Keywords: | TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-12-06 11:02:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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
|
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): fprintd-pam-0.1-19.git04fd09cfa.el6.i686 How reproducible: Always 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 3. 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.