5

I have a script that dumps a mysql database. It then compresses the file and this gets stored in my home folder by using cron. The problem is I seem to be getting an error message.

mysqldump: Couldn't execute 'show fields from `auth_group`': Can't create/write to file '/tmp/#sql_151e_0.MYI' (Errcode: 13) (1) c2duo_db-22072011.sql

Now on my centos server graphical end, it says selinx has denied access to mysqld. Ofcourse if I disable selinux this works fine. But I need selinux enabled. Is there a way around this problem?

cron

10 11 * * 5 /home/sh/mysqlbackup.sh

mysqlbackup.sh

 #!/bin/sh mysqldump -uroot -ppassword --opt c2duo_db > /home/sh/c2duo_db-`date +%d%m%Y`.sql cd /home/sh tar -zcvf c2duo_db.tgz *.sql

EDIT: Here what I get from the command grep mysqld /var/log/audit/audit.log | tail | audit2why.

type=AVC msg=audit(1311581788.889:12363): avc: denied { write } for pid=22102 comm="mysqld" path="/tmp/#sql_151e_0.MYI" dev=dm-0 ino=103481390 scontext=root:system_r:mysqld_t:s0 tcontext=root:object_r:httpd_sys_content_t:s0 tclass=file Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.

Also, my mysql server was already installed on this machine. So I guess it is an official repo.

Improve this question
4
  • 1
    There are many possible causes of, and thus solutions to this problem. Please add more information to your question: how was mysql-server installed (compiled or official repo)? What is the output of grep mysqld /var/log/audit/audit.log | tail | audit2why? (requires policycoreutils-python and auditd) Commented Jul 22, 2011 at 18:16
  • 1
    You can see the necessary allow rules by running audit2allow with this audit message as input. Have you tried this ? Commented Aug 11, 2011 at 9:03
  • Obviously problem was caused with /tmp, what user you use to run mysqldump ? Commented Sep 5, 2012 at 10:27
  • I recommend you to install: setroubleshoot-server. It would reformat audit log into human language event which would appear in /var/log/messages. Commented Nov 13, 2013 at 9:55

4 Answers 4

Reset to default
1

You probably have bad file context on /tmp directory. Show us ls -ldZ /tmp.

How is it possible that temporary file inside /tmp has httpd_sys_content_t fcontext?

type=AVC msg=audit(1311581788.889:12363): avc: denied { write } for pid=22102 comm="mysqld" path="/tmp/#sql_151e_0.MYI" dev=dm-0 ino=103481390 scontext=root:system_r:mysqld_t:s0 tcontext=root:object_r:httpd_sys_content_t:s0 tclass=file Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.

On RHEL it is:

ls -ldZ /tmp drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp

For sure it has nothing to do with path for your backup file. If it would be permission problem, you would get something like this:

# su -s /bin/bash nobody -c 'mysqldump -uroot -p123456 --opt test > /root/test-`date +%d%m%Y`.sql' bash: /root/test-13112013.sql: Permission denied

You can use strace -f -ff -o /tmp/strace mysqldump -uroot -ppassword --opt c2duo_db to see, which files it tries to open, use...

Improve this answer
0

It looks like something might be mislabeled. Have you tried running restorecon -R /var/lib/mysql?

Improve this answer
1
  • 2
    Actually restorecon -R /tmp would be better. Commented Dec 4, 2012 at 18:34
-1

I just run the command suggested by audit2why :

% echo "type=AVC msg=audit(1311581788.889:12363): avc: denied { write } for pid=22102 comm="mysqld" path="/tmp/#sql_151e_0.MYI" dev=dm-0 ino=103481390 scontext=root:system_r:mysqld_t:s0 tcontext=root:object_r:httpd_sys_content_t:s0 tclass=file" | audit2allow

This command returns :

#============= mysqld_t ============== allow mysqld_t httpd_sys_content_t:file write;

This is probably the SeLinux policy allow rule what you need.

But I don't know if allow this rule is safe ...

Improve this answer
4
  • Could you please show a 'ls -lZd /tmp', please? Commented Aug 6, 2012 at 14:55
  • 1
    This rule is definitely not safe. Commented Dec 4, 2012 at 18:33
  • Can you explain why ? Commented Dec 5, 2012 at 9:59
  • 3
    It allows MySQL to write to all of your web site content, which it has absolutely no possible legitimate reason for. Commented Jan 4, 2013 at 1:21
-1

Reason behind the issue:

The reason behind the issue is that you have placed the shell script file inside "/home/sh/"

It seems like /sh/ folder which resides under /home/ folder is not a system generated folder (one created while creating system user), instead you have created it manually. So when the cron runs the system restricts access to the scripts inside the shell script file.

Note: In linux access is restricted to the files which resides inside /home/ directory. But the files residing under /home/[directory created by system for each system user]/ has unrestricted access

Solution: 

Move the /sh/ folder along with the sh file inside a system generated folder under /home/ directory (or) create a system user named sh
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.