Bug 22466

Assigning to all packagers collectively, since there is no registered maintainer for this package.

Assignee: bugsquad => pkg-bugs
CC: (none) => marja11, 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_procedure
Version: Cauldron => 6
Assignee: mrambo => qa-bugs
Whiteboard: 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_update
CC: (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 => RESOLVED
Resolution: (none) => FIXED