Bug 10138 - 389-ds-base needs folder
: 389-ds-base needs folder
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 3
: All Linux
: Normal Severity: critical
: ---
Assigned To: QA Team
:
:
: has_procedure mga3-32-ok mga3-64-ok
: validated_update
:
: 10889
  Show dependency treegraph
 
Reported: 2013-05-18 02:00 CEST by Thomas Spuhler
Modified: 2013-08-30 19:24 CEST (History)
6 users (show)

See Also:
Source RPM: 389-ds-base
CVE:


Attachments
list of packages installed, where kolab where setup-kolab fails (15.96 KB, text/plain)
2013-07-27 04:54 CEST, Dave Hodgins
Details
list of package installed with kolab, where setup-kolab does work. (15.89 KB, text/plain)
2013-07-27 04:54 CEST, Dave Hodgins
Details
log from the setup-ds.pl script (6.50 KB, text/plain)
2013-08-18 00:17 CEST, Thomas Spuhler
Details

Description Thomas Spuhler 2013-05-18 02:00:04 CEST
Description of problem:
need to change the default group from nobody to nogroup. Mageia use nogroup instead of nobody
Need to add dir %{_sysconfdir}/system/%{groupname}.wants otherwise dirsrv instance will not start


Version-Release number of selected component (if applicable):
mga3
This bug report is entered so the change doesn't get forgotten to be pushed after the release

How reproducible:
Every time



Reproducible: 

Steps to Reproduce:
Comment 1 Thomas Spuhler 2013-07-18 17:25:53 CEST
This bug has been fixed by adding the missing directory at install. rpm is in 3/updates/testing
1. changed group nobody to nogroup
2. added Systemd directoy, %{_sysconfdir}/system/%{groupname}.wants
I have tested the updated package and the setup-kolab script now works flawless and the dirsrv instance starts every time the system is booted.

How to test:

Install kolab. It will pull all needed deps.
Give the box a real FQDN such as vbox.xyz.com
Then as root start the script: setup-kolab ( use option -d9 so you can see what's happening)
put in the infomation it asks you. 
after completion, reboot and then do a "systemctl" and see if the instance loaded such as vbox@dirserv
Comment 2 Dave Hodgins 2013-07-21 23:38:42 CEST
The setup-kolab fails after asking for the kolab password.
The fqdn of the vb guest is i3v.hodgins.homeip.net. Forward and reverse
dns do match.

Kolab Service password [L0vMpMTNvTxlCgS]: 
Confirm Kolab Service password: 
Traceback (most recent call last):
  File "/usr/sbin/setup-kolab", line 42, in <module>
    setup.run()
  File "/usr/lib/python2.7/site-packages/pykolab/setup/__init__.py", line 43, in run
    components.execute('_'.join(to_execute))
  File "/usr/lib/python2.7/site-packages/pykolab/setup/components.py", line 170, in execute
    execute(component)
  File "/usr/lib/python2.7/site-packages/pykolab/setup/components.py", line 202, in execute
    components[component_name]['function'](conf.cli_args, kw)
  File "/usr/lib/python2.7/site-packages/pykolab/setup/setup_ldap.py", line 405, in execute
    auth._auth.ldap.add_s(dn, ldif)
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 194, in add_s
    msgid = self.add(dn,modlist)
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 191, in add
    return self.add_ext(dn,modlist,None,None)
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 176, in add_ext
    return self._ldap_call(self._l.add_ext,dn,modlist,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
  File "/usr/lib/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call
    result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}

[root@i3v ~]# host i3v.hodgins.homeip.net
i3v.hodgins.homeip.net has address 192.168.10.113
[root@i3v ~]# host 192.168.10.113
113.10.168.192.in-addr.arpa domain name pointer i3v.hodgins.homeip.net.
Comment 3 Dave Hodgins 2013-07-22 00:11:14 CEST
Note that openldap-servers did not get installed, so likely just a missing
requires.
Comment 4 Dave Hodgins 2013-07-22 00:28:19 CEST
On another vb guest (x3v.hodgins.homeip.net), I tried
urpmi openldap-servers kolab
then running setup-kolab. It fails at the same point, so it looks like
it's trying to access the ldap server, before it's been started.
Comment 5 Thomas Spuhler 2013-07-22 03:11:52 CEST
openldap-servers is not needed and it may be a conflict.
the 389-ds is the ldap server.
I have on a working installation:
# rpm -qa |grep ldap
kolab-ldap-3.0.0-6.mga3
openldap-clients-2.4.33-7.mga3
ldapjdk-4.18-13.mga3
mozldap-6.0.7-2.mga3
postfix-ldap-2.9.6-4.mga3
perl-ldap-0.490.0-4.mga3
python-ldap-2.4.10-2.mga3
openldap-2.4.33-7.mga3
lib64kldap4-4.10.2-4.mga3
mozldap-tools-6.0.7-2.mga3
php-ldap-5.4.16-1.mga3
lib64ldap2.4_2-2.4.33-7.mga3
kio4-ldap-4.10.2-4.mga3

I didn't start any servers, the setup-kolab script should take care of it.
Comment 6 Thomas Spuhler 2013-07-23 21:18:53 CEST
Dave:
As mentioned in Bug #10139, I just did a fresh install of a 32bit (to check if this may has a problem) on my vbox, run the setup-script, and added users through the kolab-webadmin interface and then sent e-mail through the roundcube web interface.
Comment 7 Dave Hodgins 2013-07-24 03:18:31 CEST
There must be run time conflicts between setup-kolab, and
some of the other packages I've tested recently, or had
chosen to install.

Either I've got packages that shouldn't be installed with
389-ds-base, or packages that should not be installed before
trying to install 389-ds-base.

I can revert the vb guest to what I had after a clean install
plus updates, or would you prefer that I use what I have to
try and track down which packages are causing the conflicts?
Comment 8 Thomas Spuhler 2013-07-24 03:31:26 CEST
If you don't mind and have some time, track down the conflict, so we can add it to the rpm
Comment 9 Thomas Spuhler 2013-07-25 20:02:02 CEST
I forgot to tell you, you may need to 
# setenforce 0
I didn't have to because selinux is disabled (not working) in all of my mga3
http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Community_Installation_Guide/chap-Community_Installation_Guide-Preparing_the_System.html#sect-Community_Installation_Guide-Preparing_the_System-SELinux
Comment 10 Dave Hodgins 2013-07-27 04:54:10 CEST
Created attachment 4228 [details]
list of packages installed, where kolab where setup-kolab fails

Not using selinux. I've been digging through this, and can't figure out (yet),
why it works on a clean install, but is failing when installing to my standard
testing install.

The attached file contans the list of package installed when I install kolab
on the installation where setup-kolab fails.
Comment 11 Dave Hodgins 2013-07-27 04:54:57 CEST
Created attachment 4229 [details]
list of package installed with kolab, where setup-kolab does work.
Comment 12 Dave Hodgins 2013-07-27 04:55:50 CEST
Both of the attachments were made with Mageia 3 i586 installs, under vb.
Comment 13 Dave Hodgins 2013-07-28 04:38:12 CEST
I've tried installing all of the packages that were in the working install,
but missing from the non-working install, then installing kolab, and also
tried removing all of the packages in the non-working install, that are
missing from the working install, and then installing kolab, as well as
doing both the installing and removing, with no change.

My guess at this point, is that it's a package that is in both, but due to
configuration changes, I've made previously, as part of previous testing,
the config is not compatible with the setup-kolab script.  I normally only
revert the snapshot, if needed to test a poc for a bug.

I'm running out of ideas on how to debug this, and as I think it's unlikely
that anyone other than a qa tester would have these old config files, and be
installing this package, I'm inclined to leave this, and just test the package
on a clean install.

Opinion?
Comment 14 Thomas Spuhler 2013-07-28 21:01:49 CEST
If you had it installed before and did a setup-kolab script, you have to remove the incident, which according to the kolab folks doesn't always happen completely.
There is a remove script for it, 
remove-ds.pl <instance>
but then again, it may not always work.
Since the way I understand you, you did an upgrade of a working installation, you cannot run "setup-kolab" again. It would not work.
There were no bug reports from anybody else. I think we are fine.
Comment 15 claire robinson 2013-07-31 12:27:49 CEST
Thomas, it's difficult to know what is being updated here, there are two bugs which seem closely related. This and bug 10139.

Could you list rpms and srpms please.
Comment 16 Thomas Spuhler 2013-07-31 22:11:11 CEST
Fedora fixed it by upgrading to 1.3.1.5
Will do the same
Comment 17 Thomas Spuhler 2013-08-01 00:24:44 CEST
(In reply to Thomas Spuhler from comment #16)
> Fedora fixed it by upgrading to 1.3.1.5
> Will do the same

Ooops, wrong bug #

The updated RPMS are:
389-ds-base-1.3.0.2-2.1.mga4.src.rpm
389-ds-base-1.3.0.2-2.1.mga4.x86_64.rpm
389-ds-base-devel-1.3.0.2-2.1.mga4.xxx.rpm
389-ds-base-libs-1.3.0.2-2.1.mga4.xxx.rpm
Comment 18 David Walser 2013-08-03 16:53:19 CEST
Once all of the issues with this package are fixed, it'll need a full advisory describing the fixes.  You can use this one as a starting point:
https://bugs.mageia.org/show_bug.cgi?id=10889#c5
Comment 19 David Walser 2013-08-08 18:55:39 CEST
Assigning back to Thomas until this is ready.
Comment 20 Thomas Spuhler 2013-08-15 02:52:45 CEST
Advisory:
========================

Updated 389-ds-base packages fix problem of wrong default group nobody (from upstream) as well as the 389-ds server not starting after a reboot:

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.2.mga3
389-ds-base-libs-1.3.0.5-2.2.mga3
389-ds-base-devel-1.3.0.5-2.2.mga3

from 389-ds-base-1.3.0.5-2.2.mga3.src.rpm

These packages are fixing Bug # 10889 - 389-ds-base new security issue CVE-2013-2219
as well.
Comment 21 David Walser 2013-08-15 02:59:39 CEST
Thanks Thomas.  I guess that means the issues in this bug are fixed.

Assigning to QA.

Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.2.mga3
389-ds-base-libs-1.3.0.5-2.2.mga3
389-ds-base-devel-1.3.0.5-2.2.mga3

from 389-ds-base-1.3.0.5-2.2.mga3.src.rpm
Comment 22 Dave Hodgins 2013-08-16 05:50:38 CEST
I realize now, my prior problem was due to comment 1. I was running
setup-kolab, which is from the kolab-cli package.

Running setup-ds.pl, I chose the express setup, but it's failing.

Choose a setup type [2]: 1
The group 'nobody' is invalid.

So it looks like the script needs to be fixed too.

The advisory 10138.adv has been uploaded to svn, but will need to
be updated, once the script has been fixed.
Comment 23 Dave Hodgins 2013-08-16 06:08:51 CEST
/usr/lib/dirsrv/perl/SetupDialogs.pm:                    $username = "nobody";
/usr/lib/dirsrv/perl/SetupDialogs.pm:                    $groupname = "nobody";

Also looks like the id nobody will have to be added to the group nogroup,
which is not the case presently.
Comment 24 Thomas Spuhler 2013-08-16 19:33:18 CEST
Thanks Dave for detecting this. I never  did just a setup of the dirsrv by itself.
I always used the setup-kolab script because kolab is what I wanted.
I put a patch in for the 389-ds-base that should have taken care of this defaultgroup.
It seems, it's not working and may be an upstream bug. In anycase, one can manually change it to nogroup during the setup.
It did run it that way on my VM and the script completes.
Comment 25 Thomas Spuhler 2013-08-17 02:45:26 CEST
This bug is now fixed in subrel 3.(needed to add "autoreconf -if" to make the patch active)
The bug is no part of this report, I suggest to process this report for what it has been filed for, but no to push it into updates.
Let's open a new bug report for the nogroup/nobody problem and after approving the fix, push it into updates
Comment 26 David Walser 2013-08-17 03:02:39 CEST
We already have two bugs for this update, we don't need three.  The nobody issue is already mentioned in the advisory.
Comment 27 David Walser 2013-08-17 19:10:30 CEST
Updating package subrel in the advisory.

Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.5-2.3.mga3
389-ds-base-libs-1.3.0.5-2.3.mga3
389-ds-base-devel-1.3.0.5-2.3.mga3

from 389-ds-base-1.3.0.5-2.3.mga3.src.rpm
Comment 28 Dave Hodgins 2013-08-17 20:20:51 CEST
setup-ds.pl still fails due to
Could not open LDIF file "/root/tmp/ldifFZ06xM.ldif", errno 13 (Permission denied)
Comment 29 Thomas Spuhler 2013-08-18 00:03:31 CEST
Dave:
I run the same setup-ds.pl script on my VM and it completed fine. I can attach the log.
Comment 30 Thomas Spuhler 2013-08-18 00:17:48 CEST
Created attachment 4268 [details]
log from the setup-ds.pl script
Comment 31 David Walser 2013-08-29 00:29:15 CEST
This update is like a good game of ping-pong.

Since Thomas has responded, I've removed the feedback marker.  Dave, the ball's back in your court now :o)
Comment 32 Dave Hodgins 2013-08-29 20:28:42 CEST
Testing again shortly
Comment 33 David Walser 2013-08-29 21:09:03 CEST
A new security issue affecting this has been announced.  I'll post the details in Bug 10889 and assign this back to Thomas until it's been addressed.
Comment 34 Thomas Spuhler 2013-08-30 03:43:10 CEST
This has been fixed by upgrading to version 1.3.0.8
See Bug # 10889 for details
Re-assigning it back to qa-bugs@ml.mageia.org
Comment 35 David Walser 2013-08-30 03:47:18 CEST
Advisory:
========================

Updated 389-ds-base packages fix security vulnerability:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

It was discovered that the 389 Directory Server did not properly handle the
receipt of certain MOD operations with a bogus Distinguished Name (DN). A
remote, unauthenticated attacker could use this flaw to cause the 389
Directory Server to crash (CVE-2013-4283).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4283
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://rhn.redhat.com/errata/RHSA-2013-1182.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.8-1.mga3
389-ds-base-libs-1.3.0.8-1.mga3
389-ds-base-devel-1.3.0.8-1.mga3

from 389-ds-base-1.3.0.8-1.mga3.src.rpm
Comment 36 David Walser 2013-08-30 03:48:06 CEST
whoops, make it plural...

Advisory:
========================

Updated 389-ds-base packages fix security vulnerabilities:

It was discovered that the 389 Directory Server did not honor defined
attribute access controls when evaluating search filter expressions. A
remote attacker (with permission to query the Directory Server) could use
this flaw to determine the values of restricted attributes via a series of
search queries with filter conditions that used restricted attributes
(CVE-2013-2219).

It was discovered that the 389 Directory Server did not properly handle the
receipt of certain MOD operations with a bogus Distinguished Name (DN). A
remote, unauthenticated attacker could use this flaw to cause the 389
Directory Server to crash (CVE-2013-4283).

Additionally, problems of wrong default group nobody (from upstream) as well
as the 389-ds server not starting after a reboot have been fixed (mga#10138).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2219
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4283
https://rhn.redhat.com/errata/RHSA-2013-1119.html
https://rhn.redhat.com/errata/RHSA-2013-1182.html
https://bugs.mageia.org/show_bug.cgi?id=10138
https://bugs.mageia.org/show_bug.cgi?id=10889
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.8-1.mga3
389-ds-base-libs-1.3.0.8-1.mga3
389-ds-base-devel-1.3.0.8-1.mga3

from 389-ds-base-1.3.0.8-1.mga3.src.rpm
Comment 37 claire robinson 2013-08-30 10:46:52 CEST
Testing mga3 64

There is a traceback due to missing selinux but it does appear to complete successfully. It would be nice if this could be patched in a future update.

Directory Manager DN [cn=Directory Manager]: 
Password: 
Password (confirm): 
Traceback (most recent call last):
  File "/sbin/semanage", line 25, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 24, in <module>
    import pwd, grp, string, selinux, tempfile, os, re, sys, stat
ImportError: No module named selinux
Traceback (most recent call last):
  File "/sbin/semanage", line 25, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 24, in <module>
    import pwd, grp, string, selinux, tempfile, os, re, sys, stat
ImportError: No module named selinux
Your new DS instance 'mega' was successfully created.
Exiting . . .

It does start afterwards.

# systemctl start dirsrv@mega
# systemctl status dirsrv@mega
dirsrv@mega.service - 389 Directory Server mega.
          Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; static)
          Active: active (running) since Fri, 2013-08-30 09:36:48 BST; 4min 35s ago
         Process: 30700 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
        Main PID: 30701 (ns-slapd)
          CGroup: name=systemd:/system/dirsrv@.service/mega
                  └ 30701 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-mega -i /var/run/dirsrv/slapd-mega.pid -w /var/run/dirsrv/slapd-mega.st...

systemd[1]: Starting 389 Directory Server mega....
systemd[1]: Started 389 Directory Server mega..
systemd[1]: Started 389 Directory Server mega..


The dirsrv-snmp fails, not sure if that is expected, could you comment on this Thomas please?

# systemctl status dirsrv-snmp.service
dirsrv-snmp.service - 389 Directory Server SNMP Subagent.
          Loaded: loaded (/usr/lib/systemd/system/dirsrv-snmp.service; enabled)
          Active: failed (Result: exit-code) since Fri, 2013-08-30 09:41:05 BST; 34s ago
         Process: 31219 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/dirsrv-snmp.service

systemd[1]: Starting 389 Directory Server SNMP Subagent....
ldap-agent[31219]: ldap-agent: No server instances defined in config file
systemd[1]: Failed to start 389 Directory Server SNMP Subagent..
systemd[1]: Unit dirsrv-snmp.service entered failed state
Comment 38 claire robinson 2013-08-30 11:07:39 CEST
Can see it's started, looking in /var/log/dirsrv/slapd-<machine name>/errors
the last line is..
slapd started.  Listening on All Interfaces port 389 for LDAP requests

Checking with netstat to see it listening..
# netstat -pant | grep 389
tcp        0      0 :::389    :::*     LISTEN   30701/ns-slapd
Comment 39 claire robinson 2013-08-30 12:05:23 CEST
Testing mga3 32

As above, plus..

# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"

Shows lots of information \o/

Thomas, before validating could you comment on the dirsrv-snmp failing to start please. Is this expected or an issue?
Comment 40 claire robinson 2013-08-30 12:12:00 CEST
Advisory updated with details from comment 36
Comment 41 Thomas Spuhler 2013-08-30 17:47:09 CEST
The failing dirsrv-snmp has not been a problem so far. I believe, it's a configuration issue. But it's certainly not a regression.
The upstream wiki isn't very clear: 
http://directory.fedoraproject.org/wiki/SELinux_Policy
Comment 42 claire robinson 2013-08-30 17:54:22 CEST
OK, Validating then. Thanks Thomas.

Could sysadmin please push from 3 core/updates_testing to updates

Thanks!
Comment 43 Thomas Spuhler 2013-08-30 18:46:48 CEST
(In reply to Thomas Spuhler from comment #41)
> The failing dirsrv-snmp has not been a problem so far. I believe, it's a
> configuration issue. But it's certainly not a regression.
> The upstream wiki isn't very clear: 
> http://directory.fedoraproject.org/wiki/SELinux_Policy

I just looke further into this. I added the instance in 
/etc/dirsrv/config/ldap-agent.conf

and the server now runs.
It has to be done manually after the setup of the instance has been completed.
Comment 44 David Walser 2013-08-30 18:51:13 CEST
It might be worth making a Mageia Wiki page about all of the 389 stuff.
Comment 45 Thomas Backlund 2013-08-30 19:24:32 CEST

Update pushed:
http://advisories.mageia.org/MGASA-2013-0263.html

Note You need to log in before you can comment on or make changes to this bug.