पूरी समस्या https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662 पर उपलब्ध है; Percona के Kenny Gryp ने https://www.percona.com/blog/2016/09/12/database-affected-cve-2016-6662/ पर एक संक्षिप्त लेकिन उत्कृष्ट व्याख्या पोस्ट की है।

यह playbook एक कस्टम पैच लागू करने का प्रयास करेगा जो https://github.com/percona/percona-server/commit/c14be53e029442f576cced1fb8ff96b58e89f2e0#diff-144aa2f11374843c969d96b7b84247eaR261 में Percona पैच और https://github.com/mysql/mysql-server/blob/5.7/scripts/mysqld\_safe.sh#L356-L364 पर MySQL पैच का मिश्रण है।

यह करेगा:

• मानक patch पैकेज को स्थापित करें यदि वह मौजूद नहीं है
• which का उपयोग करके आपके mysql_safe निष्पादन योग्य का स्थान खोजें
• यदि Percona पैच लागू किया गया था तो उसे हटा दें
• mysqld_safe को पैच करने का प्रयास करें
• यदि हमने patch स्थापित किया था तो उसे फिर से हटा दें
• डिफॉल्ट्स फ़ाइलों की सूची की जाँच करें और वैकल्पिक रूप से सुरक्षित करें जिन्हें mysqld पढ़ने का प्रयास करता है

मैंने इसे लगभग सौ इंस्टॉलेशन पर सत्यापित किया है - अधिकतर Debian, कुछ RedHat और Suse वाले। यह नया संस्करण लगभग 200 होस्ट पर लागू किया गया है, जिसमें कोई स्पष्ट समस्या नहीं है।

मैंने 5.1 सेटअप पर patch विफल होते देखा है, क्योंकि mysql_safe स्क्रिप्ट में एंकर पॉइंट नहीं हैं - लेकिन वह संस्करण (और उससे नीचे) भी असुरक्षित नहीं है, इसलिए यह कोई समस्या नहीं है।

ध्यान दें कि changed= का मान 0 या 2 का अर्थ है कोई पैच नहीं किया गया (2 यदि patch स्थापित और हटा दिया गया); 1 या 3 का अर्थ है पैच किया गया। अन्य मान अप्रत्याशित हैं और उनकी जांच की जानी चाहिए :-) अतिरिक्त कार्य के साथ, यह अब इतना स्पष्ट नहीं है; आपको वास्तव में आउटपुट पढ़ना होगा।

Kenny Gryp, Percona और MySQL को स्पष्ट व्याख्या और आसान समाधान के लिए धन्यवाद; मूल पैच में दोष पकड़ने के लिए Patrick Forsberg को विशेष धन्यवाद।

/vegi