Ubuntu
openldap package

apparmor profile denied for kerberos client keytab and credential cache files

Bug #1783183 reported by Kartik Subbarao
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openldap (Ubuntu)
Fix Released
Medium
Andreas Hasenack
Trusty
Fix Released
Medium
Andreas Hasenack
Xenial
Fix Released
Medium
Andreas Hasenack
Bionic
Fix Released
Medium
Andreas Hasenack
Cosmic
Fix Released
Medium
Andreas Hasenack

Bug Description

[Impact]
When using syncrepl replication with openldap, the consumer needs to authenticate to the provider in order to perform the searches and fetch the data. When this authentication is a simple bind, a simple username/password pair is used and that can be easily supplied in a configuration file.

When one wants to use a stronger authentication mechanism, like gssapi (kerberos), the authentication is based on keytab files and tickets. The consumer needs to obtain a ticket from the KDC, and use that ticket to authenticate itself with the provider.

For users, it's a simple matter of running kinit(1) and providing a password. For services, the solution is to extract the key from the KDC and store it in a local keytab file, which is then used by the service to obtain the TGT.

Problem is this TGT expires, and needs to be renewed periodically. Solutions have popped up for that issue, the most famous one being kstart (https://www.eyrie.org/~eagle/software/kstart/), but since the MIT kerberos 1.11 release, there is a simpler way.

Via the default_client_keytab_name krb5.conf(5) option, one can specify the default location of a keytab file per local user. The kerberos library will then automatically use that file to obtain the TGT, and proceed as usual from there.

The default value of that setting is /etc/krb5/user/<uid>/client.keytab.

Turns out the openldap slapd apparmor profile doesn't account for that, and blocks attempts to read that file. It also blocks reading the TGT that is obtained and stored in /tmp/krb5cc_<uid>, resulting in such DENIED errors in the logs:

apparmor="DENIED" operation="open" profile="/usr/sbin/slapd" name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd" requested_mask="r" denied_mask="r" fsuid=389 ouid=389

apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd" name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k" denied_mask="k" fsuid=389 ouid=389

Since the slapd apparmor is enabled by default, this blocks the usage of this very helpful feature. Also considering that kerberos/gssapi errors are usually hard to debug, it might take a while for an admin to figure out what is going on.

The fix is to update the apparmor profile and allow access to those files. Unfortunately there are no rich globbing rules for paths in an apparmor profile, nothing like @{uid} of the current process yet, or a regexp rule like [0-9]+, so the rules have to be a bit accomodating. For this bug, I came up with these two new lines:

  /etc/krb5/user/*/client.keytab kr,
  owner /tmp/krb5cc_* rwk,

One could relax the first one perhaps into something like /etc/krb5/**, but the above works with the default settings.

[Test Case]
Setting up openldap replication via gssapi can be complicated, so I wrote some scripts to help.
- setup-kdc.sh: sets up the KDC server
- setup-provider.sh: sets up the openldap provider
- setup-consumer.sh: sets up the openldap consumer

The scripts expect LXD containers to be used, that have a working DNS setup for a ".lxd" domain. In other words, if you do:

lxc launch ubuntu-daily:bionic bionic-provider

The script expects the container to be reachable via "bionic-provider.lxd". That is the default behavior of LXD, and changing the scripts to work in a more generic case was deemed not worth it.

So here we go. Here are the steps for a cosmic test, just replace "cosmic" with the name of the ubuntu release you are testing.

= KDC =

* launch the KDC container and copy the setup-kdc.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-kdc
lxc file push ./setup-kdc.sh cosmic-kdc/root/

* Enter the container and run the setup-kdc.sh script:
lxc exec cosmic-kdc bash
bash ./setup-kdc.sh

* The script will show two prompts: one from debconf, with just an "ok" option, so hit ENTER there. The second prompt will be for a password. Use any one you like, it won't be needed again.

* The KDC is setup, you can exit the container.

= PROVIDER =
* launch the provider and copy the setup-provider.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-provider
lxc file push ./setup-provider.sh cosmic-provider/root/

* Enter the container and run the setup-provider.sh script:
lxc exec cosmic-provider bash
bash ./setup-provider.sh

* Leave a tail on the slapd logs, we will come back to this later:
tail -f /var/log/syslog|grep slapd

= CONSUMER =
* launch the consumer and copy the setup-consumer.sh script into it:
lxc launch ubuntu-daily:cosmic cosmic-consumer
lxc file push ./setup-consumer.sh cosmic-consumer/root/

* Enter the container and run the setup-consumer.sh script:
lxc exec cosmic-consumer bash
bash ./setup-consumer.sh

* On the provider's log tail, you should soon see a connection and immediate disconnection like this:
Oct 23 17:37:18 cosmic-provider slapd[2396]: conn=1004 fd=12 ACCEPT from IP=10.0.100.93:35276 (IP=0.0.0.0:389)
Oct 23 17:37:18 cosmic-provider slapd[2396]: conn=1004 op=0 UNBIND
Oct 23 17:37:18 cosmic-provider slapd[2396]: conn=1004 fd=12 closed

* On this consumer log, you should see an error like this:
tail /var/log/syslog |grep slapd
...
Oct 23 17:37:18 cosmic-consumer slapd[2408]: do_syncrepl: rid=001 rc -1 retrying

* On the host's log, dmesg will show an apparmor DENIED message like this:
[104159.081883] audit: type=1400 audit(1540316238.330:1881): apparmor="DENIED" operation="open" namespace="root//lxd-cosmic-consumer_<var-lib-lxd>" profile="/usr/sbin/slapd" name="/etc/krb5/user/110/client.keytab" pid=22385 comm="slapd" requested_mask="r" denied_mask="r" fsuid=165646 ouid=165536

This confirms the bug.

The replication request from the consumer to the provider will be repeated every 60s, so these messages will continue until the fixed package is installed.

To verify the fix, install the updated openldap packages on the consumer. Right after, the provider should log what is now a successful replication:
Oct 23 17:41:34 cosmic-provider slapd[2396]: conn=1009 fd=12 ACCEPT from IP=10.0.100.93:35332 (IP=0.0.0.0:389)
Oct 23 17:41:34 cosmic-provider slapd[2396]: conn=1009 op=0 BIND dn="" method=163
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=0 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=1 BIND dn="" method=163
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=1 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=2 BIND dn="" method=163
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=2 BIND authcid="consumer" authzid="consumer"
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=2 BIND dn="uid=consumer,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=2 RESULT tag=97 err=0 text=
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=3 SRCH base="dc=lxd" scope=2 deref=0 filter="(objectClass=*)"
Oct 23 17:41:39 cosmic-provider slapd[2396]: conn=1009 op=3 SRCH attr=* +

The consumer should also have a TGT file in /tmp, with the uid number of the slapd process:

root@cosmic-consumer:~# ll /tmp/krb5cc*
-rw------- 1 openldap openldap 1903 Oct 23 17:41 /tmp/krb5cc_110
root@cosmic-consumer:~# id -u openldap
110

[Regression Potential]
The fix opens up reading of a file in a subdirectory of /etc/krb5. To prevent slapd from reading other files in that directory, or other directories, the sysadmin has to use normal filesystem permissions.
In /tmp we open up writing of TGT files with a globbing pattern (krb5cc_*). The somewhat generous globbing is counteracted by the "owner" restriction we use in that rule, so that should be fine.

[Other Info]
Setting the test scenario up manually is complicated even for admins familiar with the technologies involved, so a set of scripts was used. To prevent the scripts from becoming super complicated, a specific test scenario with LXD is targeted, and error conditions are not thoroughly checked. I welcome feedback if I missed some obvious case, but the scripts won't be changed into generic tools to setup slapd gssapi replication. That is a task for a blog post or manual :)

This will be submitted to Debian as well, as reviews happen here first.

[Original Description]

Can we get /etc/krb5/** and /tmp/krb5cc_* added with the appropriate permissions to the slapd apparmor profile? I'm getting the following kinds of errors:

apparmor="DENIED" operation="open" profile="/usr/sbin/slapd" name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd" requested_mask="r" denied_mask="r" fsuid=389 ouid=389

apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd" name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k" denied_mask="k" fsuid=389 ouid=389

See original description

Related branches

~ahasenack/ubuntu/+source/openldap:disco-slapd-gssapi-apparmor-1783183
Robie Basak: Approve
Canonical Server: Pending requested
Diff: 29 lines (+10/-0)
2 files modified
debian/apparmor-profile (+2/-0)
debian/changelog (+8/-0)
~ahasenack/ubuntu/+source/openldap:trusty-slapd-gssapi-apparmor-1783183
Christian Ehrhardt  (community): Approve
Canonical Server: Pending requested
Diff: 29 lines (+10/-0)
2 files modified
debian/apparmor-profile (+2/-0)
debian/changelog (+8/-0)
~ahasenack/ubuntu/+source/openldap:xenial-slapd-gssapi-apparmor-1783183
Christian Ehrhardt  (community): Approve
Canonical Server: Pending requested
Diff: 29 lines (+10/-0)
2 files modified
debian/apparmor-profile (+2/-0)
debian/changelog (+8/-0)
~ahasenack/ubuntu/+source/openldap:bionic-slapd-gssapi-apparmor-1783183
Christian Ehrhardt  (community): Approve
Canonical Server: Pending requested
Diff: 29 lines (+10/-0)
2 files modified
debian/apparmor-profile (+2/-0)
debian/changelog (+8/-0)
~ahasenack/ubuntu/+source/openldap:cosmic-slapd-gssapi-apparmor-1783183
Christian Ehrhardt  (community): Approve
Seth Arnold (community): Approve
Canonical Server: Pending requested
Diff: 29 lines (+10/-0)
2 files modified
debian/apparmor-profile (+2/-0)
debian/changelog (+8/-0)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

"/etc/krb5/user/389/client.keytab" feels like a local modification you made, to store keytab files somewhere under /etc/krb5. I suggest you add an apparmor exception in /etc/apparmor.d/local/usr.sbin.slapd.

Unless I'm wrong and that directory is being used as a standard location by some package. Please let me know which is the case.

As to the /tpm/krb5cc_389 file, can you elaborate on the scenario that led to this behavior? Why is slapd trying to read that ticket cache file? Maybe because it failed to read the keytab file?

Changed in openldap (Ubuntu):
status: New → Incomplete
Revision history for this message
Kartik Subbarao (subbarao) wrote :

The client.keytab path is standard functionality provided by libkrb5.so in Ubuntu 18.04. Here is the relevant documentation:

http://manpages.ubuntu.com/manpages/bionic/man5/krb5.conf.5.html

       default_client_keytab_name
              This relation specifies the name of the default keytab for obtaining client
              credentials. The default is FILE:/etc/krb5/user/%{euid}/client.keytab. This
              relation is subject to parameter expansion (see below). New in release 1.11.

It gets invoked by slapd when GSSAPI is specified as the sasl mechanism (e.g. with syncrepl). This was added as a feature to libkrb5 to streamline the process of automated authentication, so that people don't have to set up cron jobs to periodically run kinit.

Regarding /tmp/krb5cc_*, that is the standard location for the credential cache file created by the kinit process. In this case, the equivalent of "kinit -k /etc/krb5/user/389/client.keytab" is done by slapd, leading to /tmp/krb5cc_389 being created.

Revision history for this message
Kartik Subbarao (subbarao) wrote :

Just to provide some more background, the specific scenarios in my case are syncrepl and a chain overlay. I have lines like this in slapd.conf:

syncrepl rid=1 provider=ldap://providerhost starttls=yes bindmethod=sasl saslmech=GSSAPI

and this:

overlay chain
chain-uri ldap://providerhost
chain-tls start
chain-idassert-bind mode=none starttls=yes bindmethod=sasl saslmech=GSSAPI

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I didn't know about default_client_keytab_name. That's definitely handy, so no more k5start needed!

Thanks for your explanation, it makes sense. I'll give it a whirl, because I'll need to add testing instructions to the change that will be proposed.

Changed in openldap (Ubuntu):
status: Incomplete → Triaged
importance: Undecided → Medium
Revision history for this message
Kartik Subbarao (subbarao) wrote :

Cool, thanks Andreas!

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Confirmed finally, sorry for the delay. I'll get this fixed.

Changed in openldap (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I used this for now:
root@bionic-slapd-consumer:/etc/apparmor.d# cat local/usr.sbin.slapd
# Site-specific additions and overrides for usr.sbin.slapd.
# For more details, please see /etc/apparmor.d/local/README.

  /etc/krb5/user/[0-9]*/client.keytab rk,
  /tmp/krb5cc_[0-9]* rwk,

I'm checking if there is some apparmor macro or variable we could use for something like "my own uid"

Andreas Hasenack (ahasenack)
description: updated
Andreas Hasenack (ahasenack)
description: updated
Andreas Hasenack (ahasenack)
description: updated
Revision history for this message
Andreas Hasenack (ahasenack) wrote :
description: updated
Changed in openldap (Ubuntu Bionic):
status: New → In Progress
Changed in openldap (Ubuntu Xenial):
status: New → In Progress
Changed in openldap (Ubuntu Trusty):
status: New → In Progress
importance: Undecided → Medium
Changed in openldap (Ubuntu Xenial):
importance: Undecided → Medium
Changed in openldap (Ubuntu Bionic):
importance: Undecided → Medium
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in openldap (Ubuntu Xenial):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in openldap (Ubuntu Trusty):
assignee: nobody → Andreas Hasenack (ahasenack)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :
Revision history for this message
Andreas Hasenack (ahasenack) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.4.46+dfsg-5ubuntu3

---------------
openldap (2.4.46+dfsg-5ubuntu3) disco; urgency=medium

  * d/apparmor-profile: update apparmor profile to allow reading of
    files needed when slapd is behaving as a kerberos/gssapi client
    and acquiring its own ticket. (LP: #1783183)

 -- Andreas Hasenack <email address hidden> Fri, 09 Nov 2018 21:29:51 -0200

Changed in openldap (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

trusty, xenial, bionic and cosmic packages uploaded to proposed, pending approval from the sru team.

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Kartik, or anyone else affected,

Accepted openldap into cosmic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.4.46+dfsg-5ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-cosmic to verification-done-cosmic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-cosmic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in openldap (Ubuntu Cosmic):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-cosmic
Changed in openldap (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Kartik, or anyone else affected,

Accepted openldap into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.4.45+dfsg-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in openldap (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Kartik, or anyone else affected,

Accepted openldap into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.4.42+dfsg-2ubuntu3.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Kartik, or anyone else affected,

Accepted openldap into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openldap/2.4.31-1+nmu2ubuntu8.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in openldap (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed-trusty
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Cosmic verification

slapd package on the consumer:
  Installed: 2.4.46+dfsg-5ubuntu1
  Candidate: 2.4.46+dfsg-5ubuntu1
  Version table:
 *** 2.4.46+dfsg-5ubuntu1 500
        500 http://br.archive.ubuntu.com/ubuntu cosmic/main amd64 Packages

Confirming failed replication attempt:
provider:
Nov 16 16:16:53 cosmic-provider slapd[2339]: conn=1004 fd=12 ACCEPT from IP=10.0.100.71:37472 (IP=0.0.0.0:389)
Nov 16 16:16:53 cosmic-provider slapd[2339]: conn=1004 op=0 UNBIND
Nov 16 16:16:53 cosmic-provider slapd[2339]: conn=1004 fd=12 closed

consumer:
Nov 16 16:16:53 cosmic-consumer slapd[2344]: slap_client_connect: URI=ldap://cosmic-provider.lxd ldap_sasl_interactive_bind_s failed (-2)
Nov 16 16:16:53 cosmic-consumer slapd[2344]: do_syncrepl: rid=001 rc -1 retrying

Host:
[sex nov 16 14:17:52 2018] audit: type=1400 audit(1542385073.436:831): apparmor="DENIED" operation="open" namespace="root//lxd-cosmic-consumer_<var-lib-lxd>" profile="/usr/sbin/slapd" name="/etc/krb5/user/110/client.keytab" pid=20151 comm="slapd" requested_mask="r" denied_mask="r" fsuid=165646 ouid=165536

Right after the consumer's openldap packages were updated, the provider logged this, showing that replication is working:
Nov 16 16:34:46 cosmic-provider slapd[2339]: conn=1022 fd=12 ACCEPT from IP=10.0.100.71:37582 (IP=0.0.0.0:389)
Nov 16 16:34:46 cosmic-provider slapd[2339]: conn=1022 op=0 BIND dn="" method=163
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=0 RESULT tag=97 err=14 text=SASL(0): successful result:
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=1 BIND dn="" method=163
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=1 RESULT tag=97 err=14 text=SASL(0): successful result:
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=2 BIND dn="" method=163
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=2 BIND authcid="consumer" authzid="consumer"
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=2 BIND dn="uid=consumer,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=2 RESULT tag=97 err=0 text=
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=3 SRCH base="dc=lxd" scope=2 deref=0 filter="(objectClass=*)"
Nov 16 16:34:51 cosmic-provider slapd[2339]: conn=1022 op=3 SRCH attr=* +

The consumer also has a tgt now in /tmp:
-rw------- 1 openldap openldap 1903 Nov 16 16:34 krb5cc_110

Consumer's packages:
root@cosmic-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.46+dfsg-5ubuntu1.1
  Candidate: 2.4.46+dfsg-5ubuntu1.1
  Version table:
 *** 2.4.46+dfsg-5ubuntu1.1 500
        500 http://br.archive.ubuntu.com/ubuntu cosmic-proposed/main amd64 Packages

Cosmic verification succeeded.

tags: added: verification-done-cosmic
removed: verification-needed-cosmic
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Bionic verification

Reproducing the bug with:
root@bionic-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.45+dfsg-1ubuntu1
  Candidate: 2.4.45+dfsg-1ubuntu1
  Version table:
 *** 2.4.45+dfsg-1ubuntu1 500
        500 http://br.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Provider logs as soon as the consumer finished setup, showing replication attempt that didn't complete:
Nov 16 16:40:30 bionic-provider slapd[1710]: conn=1004 fd=12 ACCEPT from IP=10.0.100.14:34322 (IP=0.0.0.0:389)
Nov 16 16:40:30 bionic-provider slapd[1710]: conn=1004 op=0 UNBIND
Nov 16 16:40:30 bionic-provider slapd[1710]: conn=1004 fd=12 closed

Host logs showing apparmor denied messages:
[sex nov 16 14:40:29 2018] audit: type=1400 audit(1542386430.603:919): apparmor="DENIED" operation="open" namespace="root//lxd-bionic-consumer_<var-lib-lxd>" profile="/usr/sbin/slapd" name="/etc/krb5/user/111/client.keytab" pid=17456 comm="slapd" requested_mask="r" denied_mask="r" fsuid=165647 ouid=165536

Updating the consumer's packages:
root@bionic-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.45+dfsg-1ubuntu1.1
  Candidate: 2.4.45+dfsg-1ubuntu1.1
  Version table:
 *** 2.4.45+dfsg-1ubuntu1.1 500
        500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages

Replication attempt succeeded (provider's logs):
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=2 BIND dn="" method=163
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=2 BIND authcid="consumer" authzid="consumer"
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=2 BIND dn="uid=consumer,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=2 RESULT tag=97 err=0 text=
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=3 SRCH base="dc=lxd" scope=2 deref=0 filter="(objectClass=*)"
Nov 16 16:42:42 bionic-provider slapd[1710]: conn=1007 op=3 SRCH attr=* +

Consumer has kerberos ticket in /tmp:
-rw------- 1 openldap openldap 1903 Nov 16 16:42 krb5cc_111

Bionic verification succeeded.

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

xenial verification

First confirming the bug

Package on the consumer:
root@xenial-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.42+dfsg-2ubuntu3.3
  Candidate: 2.4.42+dfsg-2ubuntu3.3
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.3 500
        500 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages

As soon as consumer setup is done, provider logs the attempted replication:
Nov 16 16:53:21 xenial-provider slapd[2189]: conn=1004 fd=13 ACCEPT from IP=10.0.100.180:40382 (IP=0.0.0.0:389)
Nov 16 16:53:21 xenial-provider slapd[2189]: conn=1004 op=0 UNBIND
Nov 16 16:53:21 xenial-provider slapd[2189]: conn=1004 fd=13 closed

Host has apparmor denied error:
[sex nov 16 14:53:21 2018] audit: type=1400 audit(1542387201.938:973): apparmor="DENIED" operation="open" namespace="root//lxd-xenial-consumer_<var-lib-lxd>" profile="/usr/sbin/slapd" name="/etc/krb5/user/112/client.keytab" pid=7896 comm="slapd" requested_mask="r" denied_mask="r" fsuid=165648 ouid=165536

Consumer also logs replication error:
Nov 16 16:53:21 xenial-consumer slapd[2024]: slap_client_connect: URI=ldap://xenial-provider.lxd ldap_sasl_interactive_bind_s failed (-2)
Nov 16 16:53:21 xenial-consumer slapd[2024]: do_syncrepl: rid=001 rc -1 retrying

Updating the packages on the consumer:
root@xenial-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.42+dfsg-2ubuntu3.4
  Candidate: 2.4.42+dfsg-2ubuntu3.4
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.4 500
        500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages

Provier logs show replication worked this time:
Nov 16 16:55:32 xenial-provider slapd[2189]: conn=1007 op=2 BIND authcid="consumer" authzid="consumer"
Nov 16 16:55:32 xenial-provider slapd[2189]: conn=1007 op=2 BIND dn="uid=consumer,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56
Nov 16 16:55:32 xenial-provider slapd[2189]: conn=1007 op=2 RESULT tag=97 err=0 text=
Nov 16 16:55:32 xenial-provider slapd[2189]: conn=1007 op=3 SRCH base="dc=lxd" scope=2 deref=0 filter="(objectClass=*)"
Nov 16 16:55:32 xenial-provider slapd[2189]: conn=1007 op=3 SRCH attr=* +

Consumer has a kerberos ticket in /tmp:
-rw------- 1 openldap openldap 1903 Nov 16 16:55 krb5cc_112

Xenial verification succeeded.

tags: added: verification-done-xenial
removed: verification-needed-xenial
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

trusty verification

reproducing the bug:
slapd:
  Installed: 2.4.31-1+nmu2ubuntu8.4
  Candidate: 2.4.31-1+nmu2ubuntu8.4
  Version table:
 *** 2.4.31-1+nmu2ubuntu8.4 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages

As soon as the consumer is setup, the provider logs the attempted replication:
Nov 16 18:24:12 trusty-provider slapd[3414]: conn=1004 fd=19 ACCEPT from IP=10.0.100.46:58678 (IP=0.0.0.0:389)
Nov 16 18:24:12 trusty-provider slapd[3414]: conn=1004 op=0 UNBIND
Nov 16 18:24:12 trusty-provider slapd[3414]: conn=1004 fd=19 closed

Consumer logs that it was a failure:
Nov 16 18:24:12 trusty-consumer slapd[3408]: slap_client_connect: URI=ldap://trusty-provider.lxd ldap_sasl_interactive_bind_s failed (-2)
Nov 16 18:24:12 trusty-consumer slapd[3408]: do_syncrepl: rid=001 rc -1 retrying

Host logs apparmor denied message:
[sex nov 16 16:24:11 2018] audit: type=1400 audit(1542392652.079:1015): apparmor="DENIED" operation="open" namespace="root//lxd-trusty-consumer_<var-lib-lxd>" profile="/usr/sbin/slapd" name="/etc/krb5/user/106/client.keytab" pid=22261 comm="slapd" requested_mask="r" denied_mask="r" fsuid=165642 ouid=165536

Updating the openldap packages on the consumer:
root@trusty-consumer:~# apt-cache policy slapd
slapd:
  Installed: 2.4.31-1+nmu2ubuntu8.5
  Candidate: 2.4.31-1+nmu2ubuntu8.5
  Version table:
 *** 2.4.31-1+nmu2ubuntu8.5 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages

Provider logs the replication:
Nov 16 18:26:15 trusty-provider slapd[3414]: conn=1007 op=2 BIND authcid="consumer" authzid="consumer"
Nov 16 18:26:15 trusty-provider slapd[3414]: conn=1007 op=2 BIND dn="uid=consumer,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=56
Nov 16 18:26:15 trusty-provider slapd[3414]: conn=1007 op=2 RESULT tag=97 err=0 text=
Nov 16 18:26:15 trusty-provider slapd[3414]: conn=1007 op=3 SRCH base="dc=lxd" scope=2 deref=0 filter="(objectClass=*)"
Nov 16 18:26:15 trusty-provider slapd[3414]: conn=1007 op=3 SRCH attr=* +

Consumer has kerberos ticket:
-rw------- 1 openldap openldap 1903 Nov 16 18:26 krb5cc_106

Trusty verification succeeded.

tags: added: verification-done-trusty
removed: verification-needed-trusty
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.4.46+dfsg-5ubuntu1.1

---------------
openldap (2.4.46+dfsg-5ubuntu1.1) cosmic; urgency=medium

  * d/apparmor-profile: update apparmor profile to allow reading of
    files needed when slapd is behaving as a kerberos/gssapi client
    and acquiring its own ticket. (LP: #1783183)

 -- Andreas Hasenack <email address hidden> Tue, 23 Oct 2018 10:06:32 -0300

Changed in openldap (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for openldap has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.4.45+dfsg-1ubuntu1.1

---------------
openldap (2.4.45+dfsg-1ubuntu1.1) bionic; urgency=medium

  * d/apparmor-profile: update apparmor profile to allow reading of
    files needed when slapd is behaving as a kerberos/gssapi client
    and acquiring its own ticket. (LP: #1783183)

 -- Andreas Hasenack <email address hidden> Tue, 23 Oct 2018 10:01:47 -0300

Changed in openldap (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.4.42+dfsg-2ubuntu3.4

---------------
openldap (2.4.42+dfsg-2ubuntu3.4) xenial; urgency=medium

  * d/apparmor-profile: update apparmor profile to allow reading of
    files needed when slapd is behaving as a kerberos/gssapi client
    and acquiring its own ticket. (LP: #1783183)

 -- Andreas Hasenack <email address hidden> Tue, 23 Oct 2018 09:47:19 -0300

Changed in openldap (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openldap - 2.4.31-1+nmu2ubuntu8.5

---------------
openldap (2.4.31-1+nmu2ubuntu8.5) trusty; urgency=medium

  * d/apparmor-profile: update apparmor profile to allow reading of
    files needed when slapd is behaving as a kerberos/gssapi client
    and acquiring its own ticket. (LP: #1783183)

 -- Andreas Hasenack <email address hidden> Mon, 22 Oct 2018 09:49:38 -0300

Changed in openldap (Ubuntu Trusty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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