Hide Forgot
Description of problem: When using socked connection for the mail system (posfix,dovecot) to connect to an local maria database, then an additional role set are needed. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-60.el7_2.7.noarch How reproducible: every every time Steps to Reproduce: 1. configure both to connect to the database via sockets. Actual results: Many denied messages form selinux. Expected results: Working connection. Additional info: audit2allow gives: require { type init_t; type usr_t; type dovecot_auth_t; type httpd_t; type postfix_cleanup_t; type shadow_t; type logrotate_t; type mysqld_db_t; type hugetlbfs_t; type postfix_master_t; class sock_file write; class unix_stream_socket connectto; class file { write read }; } #============= dovecot_auth_t ============== allow dovecot_auth_t init_t:unix_stream_socket connectto; allow dovecot_auth_t mysqld_db_t:sock_file write; #============= postfix_cleanup_t ============== allow postfix_cleanup_t mysqld_db_t:sock_file write; #============= postfix_master_t ============== allow postfix_master_t init_t:unix_stream_socket connectto; allow postfix_master_t mysqld_db_t:sock_file write;
#============= postfix_smtpd_t ============== allow postfix_smtpd_t mysqld_db_t:sock_file write; are also needed.
So it works with this local policy, correct? Thank you.
Yes.
# rpm -qa selinux\* selinux-policy-devel-3.13.1-186.el7.noarch selinux-policy-targeted-3.13.1-186.el7.noarch selinux-policy-3.13.1-186.el7.noarch # sesearch -s dovecot_auth_t -t init_t -c unix_stream_socket -p connectto -A -C -D # sesearch -s postfix_master_t -t init_t -c unix_stream_socket -p connectto -A -C -D # Unfortunately, SELinux denials in raw form are not attached. It's difficult to tell which process was running as init_t. If it was systemd then the policy is missing 2 allow rules.
Milos, Are you able to test if mail system can communicate with mariadb via sockets? If yes, let's close this and create new BZ with denials related to init_t. Thanks, Lukas.
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:3111