Bug 1822100

Summary:	semanage loses sys.stderr
Product:	Red Hat Enterprise Linux 8	Reporter:	debugitu <RedHat-Bug>
Component:	policycoreutils	Assignee:	Vit Mojzis <vmojzis>
Status:	CLOSED ERRATA	QA Contact:	Milos Malik <mmalik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.4	CC:	dwalsh, lvrabec, mmalik, plautrba, ssekidde, vmojzis
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.0	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-18 15:09:18 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:

Description debugitu 2020-04-08 09:12:08 UTC

Description of problem:
  semanage loses sys.stderr

Version-Release number of selected component (if applicable):
  In fact it is on CentOS 7, I believe that the issue is the same on EL 7.

How reproducible:
  reproducible

Steps to Reproduce:
1.
  The policycoreutils-python package must be installed.

2.
  Issue the command:
  semanage fcontext -a -t home_root_t /u

3.
  Issue the command:
  semanage fcontext -l | egrep -s -q -e '^/u .*home_root_t'

Actual results:
  The command outputs:

  close failed in file object destructor:
  sys.excepthook is missing
  lost sys.stderr

Expected results:
  No output, or
  IOError: [Errno 32] Broken pipe
  output

Additional info:
  If I just do:
  semanage fcontext -l | egrep -s -q -e ''

  I get the error message, which is normal:
  IOError: [Errno 32] Broken pipe

  So the bug is probably related to managing the local customization(s).

  There is no guarantee that there might not be more important error condition to output than simple 'Broken pipe' message.

Comment 2 debugitu 2020-04-08 09:21:46 UTC

Sorry, it is not local customization related.
If I simply do:

semanage fcontext -l | egrep -s -q -e '^/home '

I got the same error:

  close failed in file object destructor:
  sys.excepthook is missing
  lost sys.stderr

It is probably just a race condition on exit.

Comment 3 Milos Malik 2020-04-08 09:38:59 UTC

Isn't the error caused by the grep process which terminates sooner than the semanage process?

Comment 4 debugitu 2020-04-08 09:58:55 UTC

The kernel sends a 'SIGPIPE' (13) signal to the active semanage process.

The semanage process sometimes correctly gives the error message:
 IOError: [Errno 32] Broken pipe
Sometimes incorrectly outputs:
  close failed in file object destructor:
  sys.excepthook is missing
  lost sys.stderr

Comment 5 Lukas Vrabec 2020-04-23 14:56:07 UTC

This issue was not selected to be included in Red Hat Enterprise Linux 7 because it is seen either as low or moderate impact to a small number of use-cases. Current minor release will be in Maintenance Support 1 Phase, which means that qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available.

Moving the request to Red Hat Enterprise Linux 8 product.

Comment 6 Petr Lautrbach 2020-05-06 11:46:09 UTC

The problem seems to be described in Python's documentation - https://docs.python.org/3/library/signal.html#note-on-sigpipe

Comment 11 Vit Mojzis 2021-01-05 16:14:03 UTC

I wasn't able to reproduce the issue on RHEL 7.8, RHEL 8.3 or Fedora 34. The only issue I'm seeing is occasional double reporting of the "BrokenPipeError" (and "Exception ignored" warning):

#semanage fcontext -l | egrep -q -e '^/home'
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

which is caused by python flushing output on exit (as described in Comment 6).
I submitted a patch to upstream fixing this.

Are you still able to reproduce the behaviour you originally reported? If so, please share your python and policycoreutils-python(-utils) package versions or any additional steps that may help reproduce it.

Comment 12 debugitu 2021-01-05 17:21:51 UTC

I do not have 7.8 release any more, all are upgraded to 7.9.
I cannot see the reported error on 7.9.
I never tried on major release 8.

Before, the specific error was very stable, it always came. It did not seem to be a race condition, however that cannot be excluded.

If the code of the policycoreutils-python kit did not change from 7.8 to 7.9, may be the code of some underlying python library?

Comment 13 Vit Mojzis 2021-01-11 10:31:55 UTC

(In reply to debugitu from comment #12)
> I do not have 7.8 release any more, all are upgraded to 7.9.
> I cannot see the reported error on 7.9.
> I never tried on major release 8.
> 
> Before, the specific error was very stable, it always came. It did not seem
> to be a race condition, however that cannot be excluded.
> 
> If the code of the policycoreutils-python kit did not change from 7.8 to
> 7.9, may be the code of some underlying python library?

Thank you. I was thinking the same thing (change in some python I/O library).
Anyway, this is the patch (I'll merge it as soon as upstream accepts it):
https://lore.kernel.org/selinux/CAJfZ7==efgpSLs-U81UEp-0ven0mr3WZMLpP1+1XC8a-ww0uSg@mail.gmail.com/T/#t

Comment 24 errata-xmlrpc 2021-05-18 15:09:18 UTC

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 (policycoreutils bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2021:1715