dapper upgrade to hardy: user openldap is not added to group sasl

Bug #218899 reported by Martin Emrich
4
Affects Status Importance Assigned to Milestone
openldap (Ubuntu)
Won't Fix
Low
Unassigned
Hardy
Invalid
Undecided
Unassigned
openldap2.3 (Ubuntu)
Invalid
Undecided
Unassigned
Hardy
Won't Fix
Low
Unassigned

Bug Description

After upgrading from dapper to hardy, slapd can no longer authenticate against sasldb2. I found out that slapd now runs as a user "openldap", but this user has by default no rights to open /etc/sasldb2.

The postinst script should do an "adduser openldap sasl".

Tags: dapper2hardy
Revision history for this message
Chuck Short (zulcss) wrote :

Hello,

Can you provide more information about your setup?

Thanks
chuck

Changed in cyrus-sasl2:
status: New → Incomplete
Revision history for this message
Martin Emrich (emme) wrote :

Hi!

I have a pretty simple setup with libnss-ldap and libpam-ldap authenticating a locally running slapd, which in turn authenticates against sasldb. I have no saslauthd or so running.
Before upgrading from dapper to hardy, slapd ran as root, and thus was able to access /etc/sasldb2. After the upgrade, slapd now runs as a new system user "openldap".

I think this bug should be moved from source package "cyrus-sasl2" to "openldap2.3".

Ciao

Martin

Revision history for this message
Philipp Kaluza (pixelpapst) wrote :

I can confirm this. While this setup doesn't seem too common, it's certainly a valid and supported one.
This needs to be adressed on the slapd side, so reassigning this.

The suggested fix (adduser openldap sasl) is quite simple, won't cause any regressions, but does give the slapd process some more priviledges.
However, giving daemons access to /etc/sasldb2 is what the "sasl" group is _for_, after all.

An alternative might be to force use of saslauthd, provide an configuration upgrade path, test thoroughly,and document that direct access to sasldb2 is no longer supported,

I'd really recommend the former, though. :)

Changed in cyrus-sasl2:
status: Incomplete → Confirmed
Revision history for this message
Martin Emrich (emme) wrote :

+1 for _not_ using saslauthd. The first option only changes one line in /etc/group, but using saslauthd would require having another daemon running.
Furthermore, saslauthd recommends against using the sasldb backend (see saslauthd(8) for details).

Mathias Gug (mathiaz)
Changed in openldap2.3:
status: Confirmed → Invalid
Changed in openldap:
status: New → Invalid
Mathias Gug (mathiaz)
Changed in openldap:
status: New → Triaged
Changed in openldap2.3:
importance: Undecided → Low
status: New → Triaged
Changed in openldap:
status: Triaged → Confirmed
Mathias Gug (mathiaz)
Changed in openldap:
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
Mathias Gug (mathiaz) wrote :

Marking won't fix in the development release. This is an issue related to upgrades from dapper to hardy.

Adding the openldap to the sasl group by default is not an option.

Changed in openldap:
status: Triaged → Won't Fix
tags: added: dapper2hardy
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".

Changed in openldap2.3 (Ubuntu Hardy):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.