Description of problem: SELinux is preventing mysqld from 'write' accesses on the directory tables. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that mysqld should be allowed write access on the tables directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mysqld /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mysqld_t:s0 Target Context unconfined_u:object_r:httpd_user_content_t:s0 Target Objects tables [ dir ] Source mysqld Source Path mysqld Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-128.4.fc22.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.0.7-300.fc22.x86_64+debug #1 SMP Mon Jun 29 21:56:44 UTC 2015 x86_64 x86_64 Alert Count 2 First Seen 2015-07-03 12:38:10 YEKT Last Seen 2015-07-03 12:38:10 YEKT Local ID 3c219042-badb-4546-a184-0c54921dba0d Raw Audit Messages type=AVC msg=audit(1435909090.511:3055): avc: denied { write } for pid=14834 comm="mysqld" name="tables" dev="sdb1" ino=39701155 scontext=system_u:system_r:mysqld_t:s0 tcontext=unconfined_u:object_r:httpd_user_content_t:s0 tclass=dir permissive=1 Hash: mysqld,mysqld_t,httpd_user_content_t,dir,write Version-Release number of selected component: selinux-policy-3.13.1-128.4.fc22.noarch Additional info: reporter: libreport-2.6.0 hashmarkername: setroubleshoot kernel: 4.0.7-300.fc22.x86_64+debug type: libreport
What directory did yo ulabel httpd_user_content_t? Where is tables located?
*** Bug 1238974 has been marked as a duplicate of this bug. ***
*** Bug 1238973 has been marked as a duplicate of this bug. ***
*** Bug 1238972 has been marked as a duplicate of this bug. ***
*** Bug 1238971 has been marked as a duplicate of this bug. ***
*** Bug 1239001 has been marked as a duplicate of this bug. ***
*** Bug 1239000 has been marked as a duplicate of this bug. ***
*** Bug 1238999 has been marked as a duplicate of this bug. ***
*** Bug 1238998 has been marked as a duplicate of this bug. ***
*** Bug 1238997 has been marked as a duplicate of this bug. ***
We have two different problems here: 1) php-fpm process which specially runned under user synergy can't create log files in user own directory, but can read and execute php files. Why we have restriction here, if php process worked as usual linux user (not apache user)? 2) because systemd isolate mariadb daemon /tmp directory, we needed have another share place for usual linux user and mariadb service, because at current time client library couldn't export data. here registered feature request for improve situation: https://mariadb.atlassian.net/browse/MDEV-8210 If this feature request will be produced we can switch back again to /tmp directory.
Daniel, I am also read your great article http://danwalsh.livejournal.com/23944.html But I don't understand how change transition here: # cat /etc/php-fpm.d/synegry.conf [synergy] listen.owner = nginx listen.group = nginx listen = /var/run/php-fpm/synergy.sock user = synergy group = synergy pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 35 ;slowlog = /home/synergy/logs/php-fpm-slow.log ;php_admin_value[error_log] = /home/synergy/logs/php-fpm-error.log php_admin_flag[log_errors] = on ; Set session path to a directory owned by process user php_value[session.save_handler] = files php_value[session.save_path] = /tmp php_value[soap.wsdl_cache_dir] = /tmp I am able to change user and group here, but what about SELinux transitions?
If you want mariadb to write to this directory it should be labeled as mariadb content. We don't want database products to be allowed to write to users homedirectories by default. /var/log/mysql.* -- system_u:object_r:mysqld_log_t:s0 or /var/lib/mysql(/.*)? system_u:object_r:mysqld_db_t:s0 # semanage fcontext -a -t mysqldb_log_t '/home/synergy/logs(/.*)?' # restorecon -R -v /home/sysnergy Should fix the labels and allow the access.
(In reply to Daniel Walsh from comment #13) > If you want mariadb to write to this directory it should be labeled as > mariadb content. We don't want database products to be allowed to write to > users homedirectories by default. > > /var/log/mysql.* -- system_u:object_r:mysqld_log_t:s0 > or > /var/lib/mysql(/.*)? system_u:object_r:mysqld_db_t:s0 > > # semanage fcontext -a -t mysqldb_log_t '/home/synergy/logs(/.*)?' > # restorecon -R -v /home/sysnergy > > Should fix the labels and allow the access. In my situation I use server for shared hosting and each user home directory used for storing separated user web application which also needed export/import data into database. Can you offering for me better way for solving this problem? without violating the principles of SELinux.
Well it might be simpler for you to just add the allow rules. Since you trust your database but not your users, you would allow the database to write to the users homedirs. # grep mysqld /var/log/audit/audit.log | audit2allow -M mysqld # semodule -mysqld.pp Would add the rules. Either run the machine in permissive mode to generate all of the AVC's or keep on running the above commands until the AVC's stop happening.