[opensuse] Fwd: Problem with recent MySQL update, bsc#1020976, permissions on /var/run/mysql, cannot connect to MySQL

newer
[opensuse] Is anyone having issues...

Glen

14 May 2017 14 May '17

14:36

The recent update to mysql-community-server-5.6.36-24.3.3.x86_64 introduced a change to /usr/lib/mysql/mysql-systemd-helper: # diff mysql-systemd-helper.old mysql-systemd-helper 168a169,171

...

# set the default umask bsc#1020976 umask 077

After this update, and a subsequent serve reboot, the permissions on /var/run/mysql (wherein lives the mysql.sock socket) changed from 0755 to 0700. This promptly caused all of the application software and programs on my servers which communicate with MySQL to fail, with an "unable to connect" error. chmod 755 /var/run/mysql fixed the immediate connection problem, and a very hacky change to systemd: # diff mysql.service.old mysql.service 13a14

...

ExecStartPost=/usr/bin/chmod 755 /var/run/mysql

has made it persist between reboots.... for now. I have read https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html, which says:

...

This non-security issue was fixed: - Set the default umask to 077 in rc.mysql-multi [bsc#1020976]

So, I am trying to understand why this change was made (since I don't want to revert something deemed an issue) and what the correct response to this change should be. Should all my apps have "just worked anyway?" Is nobody else experiencing problems? Should I be doing something differently? The programs I run were written by different teams, and run on different servers, and they *all* failed with this patch. I can't believe that I'm the only one affected by this, and am seeking to understand what I'm doing wrong that caused all my software to get tripped up by this change, and what the most correct fixes would be to compensate/adjust on my end. Guidance, pointers, redirects all solicited and gratefully accepted! Thanks so much! Glen Glen Barney -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Show replies by date

Patrick Shanahan

14 May 14 May

14:45

* Glen [05-14-17 10:39]:

...

The recent update to mysql-community-server-5.6.36-24.3.3.x86_64 introduced a change to /usr/lib/mysql/mysql-systemd-helper:

# diff mysql-systemd-helper.old mysql-systemd-helper 168a169,171

...
# set the default umask bsc#1020976 umask 077

After this update, and a subsequent serve reboot, the permissions on /var/run/mysql (wherein lives the mysql.sock socket) changed from 0755 to 0700.

This promptly caused all of the application software and programs on my servers which communicate with MySQL to fail, with an "unable to connect" error.

chmod 755 /var/run/mysql fixed the immediate connection problem, and a very hacky change to systemd:

# diff mysql.service.old mysql.service 13a14

...
ExecStartPost=/usr/bin/chmod 755 /var/run/mysql

has made it persist between reboots.... for now.

I have read https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html, which says:

...
This non-security issue was fixed: - Set the default umask to 077 in rc.mysql-multi [bsc#1020976]

So, I am trying to understand why this change was made (since I don't want to revert something deemed an issue) and what the correct response to this change should be. Should all my apps have "just worked anyway?" Is nobody else experiencing problems? Should I be doing something differently?

The programs I run were written by different teams, and run on different servers, and they *all* failed with this patch. I can't believe that I'm the only one affected by this, and am seeking to understand what I'm doing wrong that caused all my software to get tripped up by this change, and what the most correct fixes would be to compensate/adjust on my end.

Guidance, pointers, redirects all solicited and gratefully accepted!

I am at 20170510 and have no problem with mysql after rebooting to latest kernel-default build there. you don't say which update caused your problem, but I didn't see any recent hickup. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R.

15 May 15 May

22:34

On 2017-05-14 16:45, Patrick Shanahan wrote:

...

* Glen <> [05-14-17 10:39]:

...
The recent update to mysql-community-server-5.6.36-24.3.3.x86_64 introduced a change to /usr/lib/mysql/mysql-systemd-helper:

...

...
Guidance, pointers, redirects all solicited and gratefully accepted!

I am at 20170510 and have no problem with mysql after rebooting to latest kernel-default build there. you don't say which update caused your problem, but I didn't see any recent hickup.

Carl Hartung

14 May 14 May

16:28

On Sun, 14 May 2017 07:36:24 -0700 Glen Glen wrote:

...

The recent update to mysql-community-server-5.6.36-24.3.3.x86_64 introduced a change to /usr/lib/mysql/mysql-systemd-helper:

# diff mysql-systemd-helper.old mysql-systemd-helper 168a169,171

...
# set the default umask bsc#1020976 umask 077

After this update, and a subsequent serve reboot, the permissions on /var/run/mysql (wherein lives the mysql.sock socket) changed from 0755 to 0700.

This promptly caused all of the application software and programs on my servers which communicate with MySQL to fail, with an "unable to connect" error.

chmod 755 /var/run/mysql fixed the immediate connection problem, and a very hacky change to systemd:

# diff mysql.service.old mysql.service 13a14

...
ExecStartPost=/usr/bin/chmod 755 /var/run/mysql

has made it persist between reboots.... for now.

I have read https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html, which says:

...
This non-security issue was fixed: - Set the default umask to 077 in rc.mysql-multi [bsc#1020976]

So, I am trying to understand why this change was made (since I don't want to revert something deemed an issue) and what the correct response to this change should be. Should all my apps have "just worked anyway?" Is nobody else experiencing problems? Should I be doing something differently?

The programs I run were written by different teams, and run on different servers, and they *all* failed with this patch. I can't believe that I'm the only one affected by this, and am seeking to understand what I'm doing wrong that caused all my software to get tripped up by this change, and what the most correct fixes would be to compensate/adjust on my end.

Guidance, pointers, redirects all solicited and gratefully accepted!

Thanks so much! Glen Glen Barney

Hi Glen, https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html says "Affected Products: SUSE Linux Enterprise Software Development Kit 11-SP4 SUSE Linux Enterprise Server 11-SP4 SUSE Linux Enterprise Debuginfo 11-SP4" This might explain why asking on this list is not bearing fruit. As for the origin of the update, there is this (reformatted for e-mail): From: http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html - - - - - 8< - - - - - CVE# CVE-2017-3329 Component MySQL Server Sub-component Server: Audit Plug-in Protocol MySQL Protocol Remote Exploit without Auth.? No CVSS VERSION 3.0 RISK Base Score 7.5 Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Thread Pooling). Supported versions that are affected are 5.5.54 and earlier, 5.6.35 and earlier and 5.7.17 and earlier. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. -->(CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Attack Vector Network Attack Complex Low Privs Req'd High User Interact None Scope Unchanged Confidentiality None Integrity None Availability High - - - - - 8< - - - - - I got the impression while drilling down to the above and reading through various items that many seemingly related (contemporaneous) changes appear, generally, to be addressing security & SSL & server 'hardening.' This is pure speculation on my part, but if the goal posts have been pushed forward by this process, you are likely going to have explain this latest change to your developers so they can revised their applications, accordingly. hth & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Glen

17:22

On Sun, May 14, 2017 at 8:07 AM, Patrick Shanahan wrote:

...

I have 42.2 on my server and only had to restart mysqld. no problems and I have piwigo heavily using mysql er: mariadb-client-10.0.29-18.1.x86_64

Patrick - Thank you. I'm using the mysql-community-server-client, but perhaps I have something wrong here. On Sun, May 14, 2017 at 9:28 AM, Carl Hartung wrote:

...

Hi Glen, https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html says "Affected Products: SUSE Linux Enterprise Software Development Kit 11-SP4 SUSE Linux Enterprise Server 11-SP4 SUSE Linux Enterprise Debuginfo 11-SP4"

I am so sorry to be dense, and I am sure I should know this, but I am not on any of those products. I'm just on 42.2, using the normal repos for 42.2... download.opensuse.org/update/leap/42.2/oss/ et al. And yet, that change did get pushed to me, and to all of my servers, just from the normal repo.

...

This might explain why asking on this list is not bearing fruit.

Could you recommend a place that I could go to ask? If this patch was only intended for SLES*, then does that mean it does not belong on 42.2 and was included incorrectly? Should I approach this from that angle? Or do I just go to the MySQL people? The only thing I had to go on was that "bsc" number, and that seemed to point back to OpenSUSE.

...

This is pure speculation on my part, but if the goal posts have been pushed forward by this process, you are likely going to have explain this latest change to your developers so they can revised their applications, accordingly.

I understand. I guess what I'm hoping to discover is: This patch seems to mean that connecting locally through the socket is simply no longer possible. I guess that means all connections have to be explicitly forced to e.g. [::1]:3306. That seems.... strange to me. Is that intended? Again, sorry for my confusion. Thank you both - thank you all - for your responses and patience. Glen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan

18:39

* Glen [05-14-17 13:23]: [...]

...

Patrick -

Thank you. I'm using the mysql-community-server-client, but perhaps I have something wrong here.

On Sun, May 14, 2017 at 9:28 AM, Carl Hartung wrote:

...
Hi Glen, https://lists.opensuse.org/opensuse-security-announce/2017-04/msg00036.html says "Affected Products: SUSE Linux Enterprise Software Development Kit 11-SP4 SUSE Linux Enterprise Server 11-SP4 SUSE Linux Enterprise Debuginfo 11-SP4"

I am so sorry to be dense, and I am sure I should know this, but I am not on any of those products. I'm just on 42.2, using the normal repos for 42.2... download.opensuse.org/update/leap/42.2/oss/ et al.

And yet, that change did get pushed to me, and to all of my servers, just from the normal repo.

...
This might explain why asking on this list is not bearing fruit.

Could you recommend a place that I could go to ask? If this patch was only intended for SLES*, then does that mean it does not belong on 42.2 and was included incorrectly? Should I approach this from that angle? Or do I just go to the MySQL people? The only thing I had to go on was that "bsc" number, and that seemed to point back to OpenSUSE.

...
This is pure speculation on my part, but if the goal posts have been pushed forward by this process, you are likely going to have explain this latest change to your developers so they can revised their applications, accordingly.

I understand. I guess what I'm hoping to discover is: This patch seems to mean that connecting locally through the socket is simply no longer possible. I guess that means all connections have to be explicitly forced to e.g. [::1]:3306. That seems.... strange to me. Is that intended?

Again, sorry for my confusion. Thank you both - thank you all - for your responses and patience.

42.2 is build on and closely related to SLE and the announcement Carl quotes above shows where the change comes from. Perhaps you should read it/them. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Aaron Digulla

15 May 15 May

15:22

Am Sonntag, Mai 14, 2017 16:36 CEST, Glen schrieb:

...

The recent update to mysql-community-server-5.6.36-24.3.3.x86_64 introduced a change to /usr/lib/mysql/mysql-systemd-helper:

# diff mysql-systemd-helper.old mysql-systemd-helper 168a169,171

...
# set the default umask bsc#1020976 umask 077

[...] So, I am trying to understand why this change was made (since I don't want to revert something deemed an issue) and what the correct response to this change should be.

This indicates that all your applications are using file sockets to connect to MySQL instead of, say, network sockets (TCP/IP). Maybe for performance reasons. With the change, the path to the socket file is no longer accessible to your apps and they fail. I tried to understand the security report but failed. They tend to be cryptic in order to give potential attackers not too many details how they can ruin your day until you have patched your code. I'm wondering about this patch as well. Making the socket inaccessible for anyone but the owner of the folder is a bad idea unless you can run all your apps as this user. If the folder is owned by root, that asks for "run every app as root" which is a very, very bad idea. Even if it's not root, it's bad. If the owner is "mysql" then this opens any files owned by MySQL to tampering by your app which feels wrong, too. I would understand a umask 007 with ownership mysql:mysql-apps. That way, you could create any number of users to run your applications and add them to the group "mysql-apps" so only they have access and only to this folder. That keeps everyone else out. So this is either a mistake or a bad security patch (which creates more issues than it solves) or it's a desperate measure for a very huge issue they can't talk about and which they can't fix right away. Something like "any local user can bring down MySQL" or "any local user can modify/corrupt the data". What are your options: 1. Revert the patch. 2. Create the "mysql-apps" group and modify the patch 3. Talk to your developers whether they can access MySQL without using sockets. 4. Open a support ticket with Oracle to inquire what's going on and how to fix this in your case. I wouldn't recommend #1. Security is becoming stranger every day. Just a short while ago, I learned a way how to download files from a server using just XML. #2 looks like a good short-term solution to me. There might be a security hole lurking in there which can bring your whole business down but that's the risk you have to live with anyway. At least attackers will have to break into the group before they can access the socket (which will take more time and skill since it's a single point solution just for you). I'm not sure about #3 but maybe the devs know something we don't. If you have a support contract with Oracle, use it. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2547

Age (days ago)

2548

Last active (days ago)

List overview

Download

6 comments

5 participants

participants (5)

Aaron Digulla
Carl Hartung
Carlos E. R.
Glen
Patrick Shanahan