Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1797191

Summary: SElinux is preventing nginx from accesing user_home_t
Product: Red Hat Enterprise Linux 8 Reporter: cybernet <cybernet2u>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED NOTABUG QA Contact: Milos Malik <mmalik>
Severity: unspecified Docs Contact:
Priority: low    
Version: 8.1CC: lvrabec, mmalik, plautrba, ssekidde
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-05 17:02:10 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 cybernet 2020-02-01 10:00:05 UTC
Description of problem:

Even though httpd_read_user_content --> on 
nginx can't access logs folder with the following permissions

$ ls -Z /home/dnsd
$ unconfined_u:object_r:user_home_t:s0 logs

therefore

[root@centos-2gb-fsn1-3 ~]# audit2why -w -a
type=AVC msg=audit(1580547088.127:30205): avc:  denied  { open } for  pid=8770 c                                                                                        omm="nginx" path="/home/dnsd/logs/www/error.log" dev="sda1" ino=391126 scontext=                                                                                        system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclas                                                                                        s=file permissive=1
        Was caused by:
        The boolean httpd_read_user_content was set incorrectly.
        Description:
        Allow httpd to read user content

        Allow access by executing:
        # setsebool -P httpd_read_user_content 1

$ setsebool -P httpd_read_user_content 1

And again

[root@centos-2gb-fsn1-3 ~]# audit2why -w -a
type=AVC msg=audit(1580547088.127:30205): avc:  denied  { open } for  pid=8770 c                                                                                        omm="nginx" path="/home/dnsd/logs/www/error.log" dev="sda1" ino=391126 scontext=                                                                                        system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclas                                                                                        s=file permissive=1
        Was caused by:
                Unknown - would be allowed by active policy
                Possible mismatch between this policy and the one under which th                                                                                        e audit message was generated.

                Possible mismatch between current in-memory boolean settings vs.                                                                                         permanent ones.

I got it fixed with 

[root@centos-2gb-fsn1-3 ~]# semanage fcontext -a -e /var/log/nginx /home/dnsd/lo                                                                                        gs
[root@centos-2gb-fsn1-3 ~]# restorecon -R -v /home/dnsd/logs

[root@centos-2gb-fsn1-3 ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31


[root@centos-2gb-fsn1-3 ~]# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)

[root@centos-2gb-fsn1-3 ~]# audit2why --version
audit2why .1

[root@centos-2gb-fsn1-3 ~]# uname -r
4.18.0-147.3.1.el8_1.x86_64


root access can be provided if needed

Comment 1 Milos Malik 2020-02-03 10:26:14 UTC
Do you see any "Relabeled ..." messages when running restorecon?

# semanage fcontext -a -e /var/log/nginx /home/dnsd/logs
# restorecon -Rv /home/dnsd/logs
Relabeled /home/dnsd/logs from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:httpd_log_t:s0
# matchpathcon /home/dnsd/logs/www/error.log
/home/dnsd/logs/www/error.log	system_u:object_r:httpd_log_t:s0
# 

Is it possible that the AVCs (mentioned in comment#0) appeared before you called restorecon? Because audit2why analyzes whole audit.log, which means all SELinux denials that appeared on your machine (no matter when they appeared).

If you want to see only SELinux denials which appeared recently (for example: last 10 minutes), please use ausearch:

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts recent

Comment 2 cybernet 2020-02-07 16:26:54 UTC
> Is it possible that the AVCs (mentioned in comment#0) appeared before you called restorecon?

Possible, however that label shouldnt be set by default on a fresh install ?
I have relabeled anything in /etc before i got this error. 
Weirdly enough i did another VM and the problem was gone ...
I guess this can be closed.

Comment 3 Zdenek Pytela 2020-06-05 17:02:10 UTC
These permissions are allowed in the policy:

# sesearch -A -s httpd_t -t user_home_t -c file
allow daemon user_home_t:file { append getattr };
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow httpd_t user_home_t:file map; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:file { getattr ioctl lock open read }; [ httpd_read_user_content ]:True

Turning the httpd_read_user_content boolean, the permission in the report will be granted. See the timestamps in the examples in c#0:

======
[root@centos-2gb-fsn1-3 ~]# audit2why -w -a
type=AVC msg=audit(1580547088.127:30205): avc:  denied  { open } for  pid=8770 c                                                                                        omm="nginx" path="/home/dnsd/logs/www/error.log" dev="sda1" ino=391126 scontext=                                                                                        system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclas                                                                                        s=file permissive=1
        Was caused by:
        The boolean httpd_read_user_content was set incorrectly.
        Description:
        Allow httpd to read user content

        Allow access by executing:
        # setsebool -P httpd_read_user_content 1

$ setsebool -P httpd_read_user_content 1

And again

[root@centos-2gb-fsn1-3 ~]# audit2why -w -a
type=AVC msg=audit(1580547088.127:30205): avc:  denied  { open } for  pid=8770 c                                                                                        omm="nginx" path="/home/dnsd/logs/www/error.log" dev="sda1" ino=391126 scontext=                                                                                        system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclas                                                                                        s=file permissive=1
        Was caused by:
                Unknown - would be allowed by active policy
                Possible mismatch between this policy and the one under which th                                                                                        e audit message was generated.

                Possible mismatch between current in-memory boolean settings vs.                                                                                         permanent ones.
======

The timestamp in both cases is 1580547088, i. e. refers to the state before the boolean change.

Closing as NOTABUG. Feel free to reopen the bugzilla if the issue turns out to have a different root cause.