Bug 1856308

Summary: pulseaudio fails if root owns the users home area.
Product: Red Hat Enterprise Linux 7 Reporter: Vikramsingh Patil <vikpatil>
Component: pulseaudioAssignee: Wim Taymans <wtaymans>
Status: CLOSED ERRATA QA Contact: Bill Sanford <bsanford>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.8CC: bsanford, csoriano, dbasant, mail, tpelka, wtaymans
Target Milestone: rcKeywords: Patch, Reopened, Triaged, ZStream
Target Release: 7.9   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: pulseaudio-10.0-6.el7_9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 11:20:49 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 Vikramsingh Patil 2020-07-13 11:20:03 UTC
Description of problem:
pulseaudio fails if root owns the users home area, with NAS provided home area where root owns the home area. Something to do with exporting file systems to both NFS and samba.


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

pulseaudio-10.0-5.el7.x86_64
pulseaudio-libs-10.0-5.el7.x86_64

RHEL-7.8

How reproducible:

You can reproduce the issue by changing the ownership and permission of any normal users home directory.


Steps to Reproduce:
1. check if pulseaudio is running

ps | grep pulseaudio

2. Now change the ownership as below

chown root /home/test
chmod 770 /home/test

3. Now check the status of pulse audio again

ps | grep pulseaudio

Actual results:
On checking the pulseaudio status getting below output

--
/usr/bin/pulseaudio 
E: [pulseaudio] core-util.c: Home directory not accessible: Permission denied
--

Expected results:
When checking the pulseaudio status as a normal user

--
/usr/bin/pulseaudio 
E: [pulseaudio] pid.c: Daemon already running.
--


Additional info:

As per customer's update this is a known issue with NAS provided home area where root owns the home area. Something to do with exporting file systems to both NFS and samba.

And for that there is a solution, pulseaudio have incorporated a fix with latest release.

https://gitlab.freedesktop.org/nick.moriarty/pulseaudio/commit/632f392ca76731daef2c4aca516a502b7fbf4d0f

Which customer wants us to add with our pulseaudio release for RHEL-7

Comment 2 Rob Whalley 2020-07-26 13:06:37 UTC
Hi, in the notes above it says "to add with our pulseaudio release for RHEL-7", and I was just curious as to whether this fix will also be added for RHEL-8?

For interest, we have a CentOS 8 server running a SuiteCRM cron job as the apache user, which (frustratingly) seems to invoke the pulseaudio daemon.
I can't for the life of me figure out a way to stop this from happening, so every minute we end up with the following error repeated several times in the log:

Jul 26 13:40:01 centos8 CROND[22221]: (apache) CMD (cd /var/www/suitecrm; php -f cron.php > /dev/null 2>&1)
Jul 26 13:40:01 centos8 pulseaudio[22220]: E: [pulseaudio] core-util.c: Home directory not accessible: Permission denied
Jul 26 13:40:01 centos8 systemd[22200]: pulseaudio.service: Main process exited, code=exited, status=1/FAILURE
Jul 26 13:40:01 centos8 systemd[22200]: pulseaudio.service: Failed with result 'exit-code'.
Jul 26 13:40:01 centos8 systemd[22200]: Failed to start Sound Service.

"getent passwd apache" seems to suggest that pulseaudio might see the apache user's home directory as /usr/share/httpd/ which is owned by root (setting HOME=/tmp or similar in crontab didn't help, so I don't know a way to change this behaviour).

# getent passwd apache
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin

# ls -lZa /usr/share/httpd/
total 32
drwxr-xr-x.   5 root root system_u:object_r:usr_t:s0    47 Jun  8 21:16 .
drwxr-xr-x. 307 root root system_u:object_r:usr_t:s0 12288 Jun 25 17:22 ..
drwxr-xr-x.   3 root root system_u:object_r:usr_t:s0  4096 Jun 16 07:06 error
drwxr-xr-x.   3 root root system_u:object_r:usr_t:s0  8192 Jun 16 07:06 icons
drwxr-xr-x.   3 root root system_u:object_r:usr_t:s0   140 Jun 16 07:06 noindex

So... it's possible at least that the fix mentioned above might fix this for us one day (once the CentOS distribution catches up and rebuilds their packages based on the fixed version provided by RH of course).

Obviously that won't happen for us if only RHEL-7 has the fix applied, so I thought I would at least ask the question :)

Thanks and kind regards,
Rob

Comment 8 Chris Williams 2020-11-11 21:48:05 UTC
Red Hat Enterprise Linux 7 shipped it's final minor release on September 29th, 2020. 7.9 was the last minor releases scheduled for RHEL 7.
From intial triage it does not appear the remaining Bugzillas meet the inclusion criteria for Maintenance Phase 2 and will now be closed. 

From the RHEL life cycle page:
https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase
"During Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7,Red Hat defined Critical and Important impact Security Advisories (RHSAs) and selected (at Red Hat discretion) Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available."

If this BZ was closed in error and meets the above criteria please re-open it flag for 7.9.z, provide suitable business and technical justifications, and follow the process for Accelerated Fixes:
https://source.redhat.com/groups/public/pnt-cxno/pnt_customer_experience_and_operations_wiki/support_delivery_accelerated_fix_release_handbook  

Feature Requests can re-opened and moved to RHEL 8 if the desired functionality is not already present in the product. 

Please reach out to the applicable Product Experience Engineer[0] if you have any questions or concerns.  

[0] https://bugzilla.redhat.com/page.cgi?id=agile_component_mapping.html&product=Red+Hat+Enterprise+Linux+7

Comment 10 Chris Williams 2020-11-11 23:16:35 UTC
Apologies for the inadvertent closure.

Comment 17 Bill Sanford 2020-11-24 14:54:26 UTC
This seems to be fixed with "pid.c: Daemon already running" and I am not sure if "main.c: pa_pid_file_create() failed" should be filed as another bug or it is because of the shange to the root user or it is already running.

System under test has pulseaudio-10.0-6.el7_9.x86_64

[test@rhel79 ~]$ su
Password: 
[root@rhel79 test]# chown root /home/test
[root@rhel79 test]# chmod 770 /home/test
[root@rhel79 test]# exit
exit
[test@rhel79 ~]$ ps | grep pulseaudio
[test@rhel79 ~]$ pulseaudio
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.
[test@rhel79 ~]$

Comment 21 errata-xmlrpc 2020-12-15 11:20:49 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 (pulseaudio 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-2020:5454

Comment 22 Red Hat Bugzilla 2023-09-14 06:03:48 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days