RedHat has issued an advisory today (January 25): https://access.redhat.com/errata/RHSA-2018:0163 Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11, mrambo
Assignee: pkg-bugs => mrambo
Patched package uploaded for cauldron and Mageia 6. Testing procedures: https://bugs.mageia.org/show_bug.cgi?id=11720#c7 https://bugs.mageia.org/show_bug.cgi?id=16928#c7 Advisory: ======================== Updated 389-ds-base package fixes security vulnerability: A stack buffer overflow flaw was found in the way 389-ds-base handled certain LDAP search filters. A remote, unauthenticated attacker could potentially use this flaw to make ns-slapd crash via a specially crafted LDAP request, thus resulting in denial of service (CVE-2017-15134). References: https://access.redhat.com/errata/RHSA-2018:0163 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15134 ======================== Updated packages in core/updates_testing: ======================== 389-ds-base-1.3.5.17-1.2.mga6 389-ds-base-snmp-1.3.5.17-1.2.mga6 lib64389-ds-base0-1.3.5.17-1.2.mga6 lib64389-ds-base-devel-1.3.5.17-1.2.mga6 from 389-ds-base-1.3.5.17-1.2.mga6.src.rpm
Keywords: (none) => has_procedureVersion: Cauldron => 6Assignee: mrambo => qa-bugsWhiteboard: MGA6TOO => (none)
MGA6-64 on Lenovo B50 Plasma No installation issues at CLI: # setup-ds.pl ============================================================================== This program will set up the 389 Directory Server. ...snip some ..... Would you like to continue? [no]: y ============================================================================== Choose a setup type: 1. Express Allows you to quickly set up the servers using the most common options and pre-defined defaults. Useful for quick evaluation of the products. 2. Typical Allows you to specify common defaults and options. 3. Custom Allows you to specify more advanced options. This is recommended for experienced server administrators only. To accept the default shown in brackets, press the Enter key. Choose a setup type [2]: ============================================================================== Enter the fully qualified domain name of the computer on which you're setting up server software. Using the form <hostname>.<domainname> ...snip again accepting defaults.... Directory Manager DN [cn=Directory Manager]: Password: Password (confirm): Your new DS instance 'mach5' was successfully created. Exiting . . . Log file is '/tmp/setupksw8PQ.log' checked log file, no errors. Then # systemctl start dirsrv@localhost Job for dirsrv@localhost.service failed because of unavailable resources or another system error. See "systemctl status dirsrv@localhost.service" and "journalctl -xe" for details. # systemctl -l status dirsrv@localhost.service ● dirsrv@localhost.service - 389 Directory Server localhost. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: enabled) Active: failed (Result: resources) feb 06 15:30:22 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to load environment files: No such file or directory feb 06 15:30:22 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to run 'start-pre' task: No such file or directory feb 06 15:30:22 mach5.hviaene.thuis systemd[1]: Failed to start 389 Directory Server localhost.. feb 06 15:30:22 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed with result 'resources'. and journalctl -xe does not give any feedback at all. Investigating further lateron.
CC: (none) => herman.viaene
Bumped into https://forums.fedoraforum.org/showthread.php?301716-389-ds-Unit-dirsrv-service-failed-to-load-no-such-file-or-directory and thus # start-dirsrv Starting instance "mach5" # netstat -pant | grep 389 tcp6 0 0 :::389 :::* LISTEN 17217/ns-slapd and # ldapsearch -x -h localhost -s base -b "" "objectclass=*" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: objectclass=* # requesting: ALL # # dn: objectClass: top defaultnamingcontext: dc=hviaene,dc=thuis dataversion: 020180206145002 netscapemdsuffix: cn=ldap://dc=mach5,dc=hviaene,dc=thuis:389 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So this is the same output as in previous update tests, and should be OK. Despite that # systemctl -l status dirsrv@localhost.service ● dirsrv@localhost.service - 389 Directory Server localhost. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: enabled) Active: failed (Result: resources) but it works, so I suppose I can disregard this.
Whiteboard: (none) => MGA6-64-OK
Advisory committed to svn. Validating the update.
Keywords: (none) => advisory, validated_updateCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0122.html
Status: NEW => RESOLVEDResolution: (none) => FIXED