MySQL Bugs: #57406: UMASK is ignored by error log

Bug #57406	UMASK is ignored by error log
Submitted:	12 Oct 2010 14:40	Modified:	14 Nov 2012 14:12
Reporter:	Nicklas Westerlund (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Logging	Severity:	S2 (Serious)
Version:	5.5.6 & 5.1.49, 5.1.51	OS:	Linux
Assigned to:		CPU Architecture:	Any

Description:
According to the documention, setting the user variable UMASK and exporting it will make MySQL create any files utilizing that mode.

"
•If UMASK is set, mysqld uses ($UMASK | 0600) as the mode for file creation, so that newly created files have a mode in the range from 0600 to 0666 (all values octal).
"

However, it seems that this is not true for the .err file, which in a way I can understand as it could pose a security risk. However, in our case monitoring software depends on being able to read that file, and we do not wish to add that user to the mysql group, so we change the permissions to 0644 instead, which of course does not stick after a flush logs and thus we get a warning about it. The pid file does change.

Here is the original before changing the UMASK/mode:

-rw-rw---- 1 mysql mysql 923 Oct 12 14:20 dbatestlabmydb1b.err
-rw-rw---- 1 mysql mysql 5 Oct 12 14:20 dbatestlabmydb1b.pid

Then I remove them, set UMASK and export it, start the server again:

-rw-rw---- 1 mysql mysql 923 Oct 12 14:22 dbatestlabmydb1b.err
-rw-r--r-- 1 mysql mysql 5 Oct 12 14:22 dbatestlabmydb1b.pid

How to repeat:
1) Start a server, shut it down again.
2) remove errorlog
3) UMASK=0644 && export UMASK
4) Start the server
5) ls -al /path/to/errorlog

Suggested fix:
Make the creation process of .err obey the my_umask that is being set by UMASK from user env.

Please see Tatjana A. Nuernberg's comment on #35090 for a description of how my_umask is used in the server.

Thank you for the report.

I can not repeat described behavior with current development sources:

$UMASK=0644  ./libexec/mysqld --defaults-file=./support-files/my-small.cnf  --basedir=. --datadir=./data --log-error --port=33051  --socket=/tmp/mysql_ssmirnova.sock  &
[1] 14664

$101012 17:56:49 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-locking' instead.

$ls -la data
total 65236
drwx------ 11 ssmirnova ssmirnova     8192 Oct 12 17:56 .
drwxr-xr-x 18 ssmirnova ssmirnova     4096 Oct  9 08:15 ..
-rw-rw----  1 ssmirnova ssmirnova  3085780 Aug 21 18:57 host-bin.000001
-rw-rw----  1 ssmirnova ssmirnova       21 Aug 21 18:53 host-bin.index
-rw-r--r--  1 ssmirnova ssmirnova      392 Oct 12 17:56 host.err
-rw-r--r--  1 ssmirnova ssmirnova        6 Oct 12 17:56 host.pid
...

Please try with current version 5.1.51 and if problem still exists indicate accurate name and version of operating system you are running.

Hi Sveta,

UMASK=0644
export UMASK
./bin/mysqld_safe --no-defaults --datadir=/mysqldata/nick/51/data --basedir=/mysqldata/nick/51 --port=9999 --skip-name-resolve &

[mysql@dbatestlabmydb1b 51]$ ls -al data
total 20544
drwxr-x---  4 mysql mysql     4096 Oct 12 18:22 .
drwxr-xr-x 13 mysql mysql     4096 Sep 13 16:17 ..
-rw-rw----  1 mysql mysql     1114 Oct 12 18:22 dbatestlabmydb1b.err
-rw-r--r--  1 mysql mysql        6 Oct 12 18:22 dbatestlabmydb1b.pid
-rw-rw----  1 mysql mysql 10485760 Oct 12 18:20 ibdata1
-rw-rw----  1 mysql mysql  5242880 Oct 12 18:21 ib_logfile0
-rw-rw----  1 mysql mysql  5242880 Oct 12 18:21 ib_logfile1
drwxr-x---  2 mysql mysql     4096 Oct 12 18:20 mysql
drwxr-x---  2 mysql mysql     4096 Sep 13 16:17 test

the ibdata + iblogs was created on first startup, without using the umask.

OS is RHEL 5.4

[mysql@dbatestlabmydb1b 51]$ uname -srmpion
Linux dbatestlabmydb1b 2.6.18-128.el5 x86_64 x86_64 x86_64 GNU/Linux

[mysql@dbatestlabmydb1b 51]$ tail -2 data/*.err
101012 18:22:01 [Note] /mysqldata/nick/51/bin/mysqld: ready for connections.
Version: '5.1.51'  socket: '/tmp/mysql.sock'  port: 9999  MySQL Community Server (GPL)

Nicklas,

thank you for the feedback. Verified as described, but error log is mysqld_safe issue. Workaround: start mysqld directly. Can be duplicate of bug #28043

Thanks.

I'm not so sure I want to use that workaround however, it requires changing the /etc/init.d/mysql file, and without mysqld_safe  we run a higher risk of the db going down and not coming back up automatically.  I'll discuss it - thanks for the workaround and the verification.

Hi Nicklas, you can modify mysqld_safe:

shell> grep umask mysqld_safe 
umask 007

Noted in 5.1.67, 5.5.29, 5.6.9, 5.7.0 changelogs.

mysqld_safe ignored the value of the UMASK environment variable,
leading to behavior different from mysqld with respect to the access
mode of created files. Now mysqld_safe (and mysqld_multi) attempt to
approximate the same behavior as mysqld.