Fedora has issued advisories on August 7: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JXGWOJNSWWK2TTWQJZJUP66FLFIWDMBQ/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/DTPDZV4ZRICDYAYZVUHSYZAYDLRMG2IM/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/4GMSCGMM477N64Z3BM34RWYBGSLK466B/ The issue is fixed in 3.0.1, 3.1.4, 3.2.4, and 3.3.3. Upstream patches are linked from the RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1476143 Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO, MGA5TOOCC: (none) => geiger.david68210
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => juan.baptiste, marja11Assignee: bugsquad => pkg-bugs
just pushed on mga5/6 src.rpm: supervisor-3.1.4-1.mga6 supervisor-3.0.1-1.mga5 pushed in cauldron too
CVE: (none) => CVE-2017-11610CC: (none) => mageiaAssignee: pkg-bugs => qa-bugs
Advisory: ======================== Updated supervisor package fixes security vulnerability: A vulnerability has been found where an authenticated client can send a malicious XML-RPC request to supervisord that will run arbitrary shell commands on the server. The commands will be run as the same user as supervisord. Depending on how supervisord has been configured, this may be root (CVE-2017-11610). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11610 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/JXGWOJNSWWK2TTWQJZJUP66FLFIWDMBQ/ ======================== Updated packages in core/updates_testing: ======================== supervisor-3.0.1-1.mga5 supervisor-3.1.4-1.mga6 from SRPMS: supervisor-3.0.1-1.mga5.src.rpm supervisor-3.1.4-1.mga6.src.rpm
Version: Cauldron => 6Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
Checking this out for mga5 x86_64. It may take a while.
CC: (none) => tarazed25
In VirtualBox, M6, Plasma, 64-bit Package(s) under test: supervisor default install of supervisor installs: - python-meld3-0.6.7-2.mga6.x86_64 - python-pkg-resources-19.6.2-1.mga6.noarch - python-setuptools-19.6.2-1.mga6.noarch - supervisor-3.1.3-1.mga6.noarch [root@localhost wilcal]# urpmi supervisor Package supervisor-3.1.3-1.mga6.noarch is already installed use supervisor in an su window: [root@localhost wilcal]# supervisord ( kicks things off ) [root@localhost wilcal]# supervisorctl supervisor> supervisor> help presents a listing of single word commands many of which do something one is: supervisor> version 3.1.3 another is: supervisor> quit install supervisor from updates_testing updating packages: - lib64rpm7-4.13.0.1-3.mga6.x86_64 - python2-rpm-4.13.0.1-3.mga6.x86_64 - python3-rpm-4.13.0.1-3.mga6.x86_64 - rpm-4.13.0.1-3.mga6.x86_64 - supervisor-3.1.4-1.mga6.noarch [root@localhost wilcal]# urpmi supervisor Package supervisor-3.1.4-1.mga6.noarch is already installed use supervisor in an su window: [root@localhost wilcal]# supervisord ( kicks things off ) [root@localhost wilcal]# supervisorctl supervisor> supervisor> help presents a listing of single word commands many of which do something one is: supervisor> version 3.1.4 supervisor> quit Without becoming a supervisor expert it seems to work.
CC: (none) => wilcal.int
In VirtualBox, M6, Mate, 32-bit Package(s) under test: supervisor default install of supervisor installs: - python-meld3-0.6.7-2.mga6.i586 - python-pkg-resources-19.6.2-1.mga6.noarch - python-setuptools-19.6.2-1.mga6.noarch - supervisor-3.1.3-1.mga6.noarch [root@localhost wilcal]# urpmi supervisor Package supervisor-3.1.3-1.mga6.noarch is already installed use supervisor in an su window: [root@localhost wilcal]# supervisord ( kicks things off ) [root@localhost wilcal]# supervisorctl supervisor> supervisor> help presents a listing of single word commands many of which do something one is: supervisor> version 3.1.3 another is: supervisor> quit install supervisor from updates_testing updating packages: - lib64rpm7-4.13.0.1-3.mga6.x86_64 - python2-rpm-4.13.0.1-3.mga6.x86_64 - python3-rpm-4.13.0.1-3.mga6.x86_64 - rpm-4.13.0.1-3.mga6.x86_64 - supervisor-3.1.4-1.mga6.noarch [root@localhost wilcal]# urpmi supervisor Package supervisor-3.1.4-1.mga6.noarch is already installed use supervisor in an su window: [root@localhost wilcal]# supervisord ( kicks things off ) [root@localhost wilcal]# supervisorctl supervisor> supervisor> help presents a listing of single word commands many of which do something one is: supervisor> version 3.1.4 supervisor> quit Without becoming a supervisor expert it seems to work.
In VirtualBox, M5, KDE, 32-bit David, I've run into some significant operational aspects of running supervisor on M5. I can't tell if it's something I don't understand or whatever. It preforms very differently, with errors, then M6. How important is this package? Maybe someone else can try this on M5 and see how successful they are?
In VirtualBox, M5, KDE, 64-bit Package(s) under test: supervisor default install of supervisor [root@localhost wilcal]# urpmi supervisor Package supervisor-3.0.1-1.mga5.noarch is already installed [root@localhost wilcal]# supervisord Traceback (most recent call last): File "/usr/bin/supervisord", line 9, in <module> load_entry_point('supervisor==3.0.1', 'console_scripts', 'supervisord')() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 356, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2431, in load_entry_point return ep.load() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2147, in load ['__name__']) File "/usr/lib/python2.7/site-packages/supervisor/supervisord.py", line 41, in <module> from supervisor.options import ServerOptions File "/usr/lib/python2.7/site-packages/supervisor/options.py", line 57, in <module> VERSION = open(version_txt).read().strip() IOError: [Errno 2] No such file or directory: '/usr/lib/python2.7/site-packages/supervisor/version.txt' And it won't start.
M6 seemed to go smoothly although minimalist testing.
@wilcal re comment 7. On mga5 I got about as far as you did with supervisor on mga6. Under Mate it has been running as a daemon for about a day. I used systemctl to enable supervisord and then start it. # systemctl status supervisord ● supervisord.service - Process Monitoring and Control Daemon Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled) Active: active (running) since Thu 2017-08-10 19:06:09 BST; 22h ago Process: 5621 ExecStart=/usr/bin/supervisord (code=exited, status=0/SUCCESS) Main PID: 5660 (supervisord) CGroup: /system.slice/supervisord.service └─5660 /usr/bin/python /usr/bin/supervisord Aug 10 19:06:09 vega supervisord[5621]: /usr/lib/python2.7/site-packages/supe... Aug 10 19:06:09 vega supervisord[5621]: 'Supervisord is running as root and ...' Have not tried the update yet, or running under KDE.
mga5 x86_64 KDE4 Installed supervisor and ran supervisord from a root commandline. It started OK. Used supervisorctl to dip into the help system. $ systemctl status supervisord ● supervisord.service - Process Monitoring and Control Daemon Loaded: loaded (/usr/lib/systemd/system/supervisord.service; disabled) Active: inactive (dead) # systemctl enable supervisord Created symlink from /etc/systemd/system/multi-user.target.wants/supervisord.service to /usr/lib/systemd/system/supervisord.service. # systemctl start supervisord.service Job for supervisord.service failed. See "systemctl status supervisord.service" and "journalctl -xe" for details. # systemctl restart supervisord.service Job for supervisord.service failed. See "systemctl status supervisord.service" and "journalctl -xe" for details. # killall supervisord # ps aux | grep supervisor root 3876 0.0 0.0 12248 2184 pts/0 S+ 18:27 0:00 grep --color supervisor # systemctl start supervisord.service # systemctl status supervisord.service ● supervisord.service - Process Monitoring and Control Daemon Loaded: loaded (/usr/lib/systemd/system/supervisord.service; enabled) Active: active (running) since Fri 2017-08-11 18:27:37 BST; 50s ago Process: 3890 ExecStart=/usr/bin/supervisord (code=exited, status=0/SUCCESS) Main PID: 3894 (supervisord) CGroup: /system.slice/supervisord.service └─3894 /usr/bin/python /usr/bin/supervisord So, there do not appear to be any real difficulties with running supervisor under KDE4. But, I have not checked vbox operation. # ls -l /usr/lib/python2.7/site-packages/supervisor/version.txt -rw-r--r-- 1 root root 4 Nov 14 2014 /usr/lib/python2.7/site-packages/supervisor/version.txt That contains "3.0" and nothing else. @wilcal: Could you check if that file does exist and what the permissions are? And if it does not exist, as the error message implies try touching it. # echo 3.0 > /usr/lib/python2.7/site-packages/supervisor/version.txt That should at least get you one more step forward.
If your happy with this thing in M5 then lets push it on. The exposure is less then 90-days and I see no problems in M6
We have not explored the possibilities but if you are happy so am I.
Whiteboard: MGA5TOO => MGA5TOO MGA5-64-OK
Whiteboard: MGA5TOO MGA5-64-OK => MGA5TOO MGA5-64-OK MGA6-632-OK MGA6-64-OK
This update works fine. Testing complete for MGA5, 32-bit & 64-bit Validating the update. Could someone from the sysadmin team push to updates. Thanks
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
Whiteboard: MGA5TOO MGA5-64-OK MGA6-632-OK MGA6-64-OK => MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-632-OK MGA6-64-OK
Whiteboard: MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-632-OK MGA6-64-OK => MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-32-OK MGA6-64-OK
Whiteboard: MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-32-OK MGA6-64-OK => MGA5TOO MGA5-32-OK MGA5-64-OK MGA6-32-OK MGA6-64-OK advisoryCC: (none) => lewyssmith
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0263.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED