Could you run following commands and attach their output?

# rpm -qa selinux-policy\*

# getsebool -a | grep http

#  rpm -qa selinux-policy\*
selinux-policy-targeted-3.13.1-166.el7_4.4.noarch
selinux-policy-3.13.1-166.el7_4.4.noarch
# getsebool -a | grep http
httpd_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_mythtv --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_dbus_sssd --> off
httpd_dontaudit_search_dirs --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_execmem --> off
httpd_graceful_shutdown --> on
httpd_manage_ipa --> off
httpd_mod_auth_ntlm_winbind --> off
httpd_mod_auth_pam --> off
httpd_read_user_content --> on
httpd_run_ipa --> off
httpd_run_preupgrade --> off
httpd_run_stickshift --> off
httpd_serve_cobbler_files --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_sys_script_anon_write --> off
httpd_tmp_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_use_openstack --> off
httpd_use_sasl --> off
httpd_verify_dns --> off
named_tcp_bind_http_port --> off
prosody_bind_http_port --> off

If you enable the httpd_unified boolean, your scenario should work:

# sesearch -s httpd_t -t httpd_user_content_t -c dir -A -C -p read
Found 7 semantic av rules:
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
DT allow httpd_t httpdcontent : dir { ioctl read write getattr lock add_name remove_name search open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]

#

I must admit that description of the boolean is not as explanatory as it could be.

# semanage boolean -l | grep unified
httpd_unified                  (off  ,  off)  Unify HTTPD handling of all content files.
#

From what I read of that boolean it seems like a way too big of a hammer for this. It seems to turn off a lot of protection for httpd?

Why isn't read of httpd_user_content_t dirs allowed when read of files with the same type is just fine?

Lukas, can you answer the question please?

Seeing this on CentOS 7.4 as well. Using the httpd_unified boolean works around this issue for me.

In my case it was php-fpm not being able to read httpd_user_content_t directories.

Correction, httpd_unified does not fix php-fpm, it was a cache fluke.

Was the needinfo cleared by mistake there? :)

I have used this custom module to work around the issue in my environment which allows what Pierre described earlier. It does fix the issues I had with php-fpm.

-- snip --
module httpd_user_read_dir 1.0;

require {
        type httpd_user_content_t;
        type httpd_t;
        class dir read;
}

#============= httpd_t ==============
allow httpd_t httpd_user_content_t:dir read;
-- snap --

Hi, 

Actually this is not a bug, it's a feature! :) 

We have two similar booleans:
httpd_read_user_content
httpd_enable_homedirs

You're trying to use httpd_read_user_content, this boolean contains following rules: 

# sesearch -A -s httpd_t | grep httpd_read_user_content
allow httpd_t home_root_t:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t home_root_t:lnk_file { getattr read }; [ httpd_read_user_content ]:True
allow httpd_t user_home_dir_t:dir { getattr ioctl lock open read search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_dir_t:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_dir_t:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_dir_t:lnk_file { getattr read }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr ioctl lock open read search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:file { getattr ioctl lock open read }; [ httpd_read_user_content ]:True

Attribute user_home_type contains following types: 
# seinfo -xauser_home_type

Type Attributes: 1
   attribute user_home_type;
	alsa_home_t
	antivirus_home_t
	audio_home_t
	auth_home_t
	cache_home_t
	chrome_sandbox_home_t
	config_home_t
	container_home_t
	cvs_home_t
	data_home_t
	dbus_home_t
	fetchmail_home_t
	gconf_home_t
	git_user_content_t
	gkeyringd_gnome_home_t
	gnome_home_t
	gpg_secret_t
	gstreamer_home_t
	home_bin_t
	home_cert_t
	icc_data_home_t
	iceauth_home_t
	irc_home_t
	irc_tmp_t
	irssi_home_t
	kismet_home_t
	krb5_home_t
	local_login_home_t
	mail_home_rw_t
	mail_home_t
	mandb_home_t
	mozilla_home_t
	mpd_home_t
	mpd_user_data_t
	mplayer_home_t
	mysqld_home_t
	openshift_var_lib_t
	polipo_cache_home_t
	polipo_config_home_t
	procmail_home_t
	pulseaudio_home_t
	rlogind_home_t
	rssh_ro_t
	rssh_rw_t
	sandbox_file_t
	screen_home_t
	spamc_home_t
	speech-dispatcher_home_t
	ssh_home_t
	svirt_home_t
	systemd_home_t
	telepathy_cache_home_t
	telepathy_data_home_t
	telepathy_gabble_cache_home_t
	telepathy_logger_cache_home_t
	telepathy_logger_data_home_t
	telepathy_mission_control_cache_home_t
	telepathy_mission_control_data_home_t
	telepathy_mission_control_home_t
	telepathy_sunshine_home_t
	texlive_home_t
	thumb_home_t
	tvtime_home_t
	uml_ro_t
	uml_rw_t
	user_fonts_cache_t
	user_fonts_config_t
	user_fonts_t
	user_home_t
	user_tmp_t
	virt_content_t
	virt_home_t
	vmware_conf_t
	vmware_file_t
	wine_home_t
	wireshark_home_t
	xauth_home_t
	xdm_home_t
as you can see there is no httpd_user_content_t which is good. 

Boolean httpd_enable_homedirs is for your case, when you would like to have webpages in your home dir. 

Boolean httpd_read_user_content you can read (almost) all files in user homedir which is something different. 

Following command should fix your issue:

# semanage boolean -m httpd_enable_homedirs --on 

Lukas.

Please let us know if comment#11 helps. 

Thanks,
Lukas.

I'm afraid it does not. httpd_enable_homedirs is already "on", but that is insufficient (as mentioned in the original comment creating this bug).

The issue is not about httpd_user_content_t in general. This is about *directories* with that type. They are for some reason locked down now, but not files. And neither are httpd_user_rw_content_t directories. And it's a regression.

So all in all this reeks of a a bug where someone accidentally removed a "allow httpd_t httpd_user_content_t:dir read" line somewhere. :)

You are right, sorry I see it know. 

Fixed in Fedora Rawhide, F27, F26 and it will be part of next minor release of RHEL.

I don't mean to be rude but this is rather critical for anyone using SELinux with httpd and user directories and if it was a honest mistake and a regression, couldn't this be pushed before a minor release?

As 7.4 was released just a few months ago it will take very long for this to land in production and I suspect this will encourage more people to disable SELinux as you can't work around it without a custom module for now.

Thanks.

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, 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-2018:0763