Bug #15105 mysqld ignores umask when creating its unix socket
Submitted: 21 Nov 2005 18:09 Modified: 25 Nov 2005 17:20
Reporter: [ name withheld ] Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: General Severity:S4 (Feature request)
Version:5.0.17-BK, 4.0.24 OS:Linux (Linux, sun-solaris2.10 on sparc)
Assigned to: CPU Architecture:Any
Triage: Triaged: D5 (Feature request)

[21 Nov 2005 18:09] [ name withheld ]
Description:
Background: I have an ordinary user account, and I want to set up a private mysqld server using the software that's been installed by the sysadm. That's why I don't run the latest version.

My server is not intended to be accessible to anybody else. So I naturally turned off tcpip networking. I started mysqld using

  mysqld --defaults-file=$HOME/.../my.cnf --datadir=$HOME/.../data --socket=$HOME/.../mysql.sock

and a config file containing only

  [server]
  skip-networking

I set my umask to 077 before starting the server. I was disappointed to find that the socket was created as 

  srwxrwxrwx    1 nisse    lysator         0 Nov 21 14:46 mysql.sock=

I.e. the socket is accessible to anyone logged in on the machine. I would prefer to have the permissions srwx------.

I searched in the manual for an option to control these permissions, without finding any (let me know if I missed something). Using truss, I see the following system calls:

  umask(06)                                       = 077
  chdir("/home/nisse/hack/xenofarm/mysql/data/")  = 0
  getuid()                                        = 444 [444]
  so_socket(PF_UNIX, SOCK_STREAM, 0, "", SOV_DEFAULT) = 3
  unlink("/home/nisse/hack/xenofarm/mysql/mysql.sock") Err#2 ENOENT
  setsockopt(3, SOL_SOCKET, SO_REUSEADDR, 0xFFBFF7C4, 4, SOV_DEFAULT) = 0
  umask(0)                                        = 06
  bind(3, 0xFFBFF744, 110, SOV_SOCKBSD)           = 0
  umask(06)                                       = 0

I.e., mysqld explicitly ignores the umask and creates a world-accessible socket. I think it should either respect the user's umask, or provide some other option to set more paranoid permissions on the socket.

Regards,
/Niels Möller

How to repeat:
Use the --socket option when starting mysqld.

Suggested fix:
Don't modify umask unless explicitly asked to.
[21 Nov 2005 18:28] Valeriy Kravchuk
Thank you for a problem report. I'll try to check on Linux first. Even if it is true that umask is ignored, you may just put your socket into the directory not readable and not executable by nobody else but you.
[25 Nov 2005 15:06] Valeriy Kravchuk
Thank you for a problem report. Yes, umask values are ignored when creating sockets. Moreover, the access rights are reset upon each startup:  Verified on 5.0.17-BK () on Linux:

[openxs@Fedora 5.0]$ ls -l ~/*.sock
srwxrwxrwx    1 openxs   openxs          0 Sep  1 18:26 /home/openxs/mysql5.sock

[openxs@Fedora 5.0]$ umask 077
[openxs@Fedora 5.0]$ umask
0077
[openxs@Fedora 5.0]$ bin/mysqld_safe --socket=/home/openxs/mynew.sock &
[1] 7705
[openxs@Fedora 5.0]$ Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var

[openxs@Fedora 5.0]$ ls -l ~/*.sock
srwxrwxrwx    1 openxs   openxs          0 Sep  1 18:26 /home/openxs/mysql5.sock

[openxs@Fedora 5.0]$ chmod 700 ~/mynew.sock
[openxs@Fedora 5.0]$ ls -l ~/*.sock
srwx------    1 openxs   openxs          0 Nov 25 17:49 /home/openxs/mynew.sock

[openxs@Fedora 5.0]$ bin/mysqladmin -uroot --socket=/home/openxs/mynew.sock shutdown;
STOPPING server from pid file /home/openxs/dbs/5.0/var/Fedora.pid
051125 17:56:08  mysqld ended

[1]+  Done                    bin/mysqld_safe --socket=/home/openxs/mynew.sock

[openxs@Fedora 5.0]$ bin/mysqld_safe --socket=/home/openxs/mynew.sock &
[1] 7856
[openxs@Fedora 5.0]$ Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var

[openxs@Fedora 5.0]$ ls -l ~/*.sock
srwxrwxrwx    1 openxs   openxs          0 Nov 25 17:56 /home/openxs/mynew.sock

I am not sure that socket permissions is a problem (anybody can send packet to port 3306, so what?), but let the developers check is it really the intended behaviour.
[25 Nov 2005 15:14] [ name withheld ]
About your comment "anybody can send packet to port 3306, so what?":

In my configuration, I had explicitly used as the goal was to have a private database server not accessible to anybody else. So there was nobody listening on port 3306.

/Niels
[25 Nov 2005 17:20] [ name withheld ]
Sorry, the word "skip-networking" was lost in my previous comment. 

I had explicitly used the option --skip-networking to disable listening on port 3306.

/Niels