[snap] kerberos GSSAPI no longer works after deb->snap transition

Bug #1849346 reported by st0ve on 2019-10-22
This bug affects 7 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
thunderbird (Ubuntu)

Bug Description

I configure AuthServerWhitelist as documented:


and can see my whitelisted domains in chrome://policy/

but websites that used to work with SPNEGO/GSSAPI/kerberos no longer work. I'm guessing the snap needs some sort of permission to use the kerberos ticket cache (or the plumbing to do so doesn't exist...).

I can confirm that Chrome has the desired behavior.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
st0ve (st0ve) on 2019-10-25
description: updated
st0ve (st0ve) on 2019-10-28
summary: - kerberos GSSAPI no longer works after deb->snap transition
+ [snap] kerberos GSSAPI no longer works after deb->snap transition
Olivier Tilloy (osomon) wrote :

Thanks for the report.
Can you check for apparmor denials in the system journal when reproducing the problem? Run the following command in a terminal before launching chromium:

    journalctl -f | grep DEN

tags: added: snap
st0ve (st0ve) wrote :

The /etc/gss/mech.d/ and /etc/krb5.conf.d/ denials may be relevant. Both directories are empty in my case, but lack of access may be killing some logic that relies on checking them.

Olivier Tilloy (osomon) wrote :

Thanks, that's useful.

I'm not familiar with SPNEGO/GSSAPI/kerberos, could you maybe come up with easy steps to reproduce the problem on a clean system? That would allow me to dig further into the problem.

The same problem here, after upgrading to 'snapped' chromium 79 we lost Single Sign-On, all our Kerberos security based intranet web servers started asking for username and password.

Kerberos ticket cache is file /tmp/krb5cc_<uid>:
johndoe@computer:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: <email address hidden>

Valid starting Expires Service principal
3.2.2020 12:39:10 3.2.2020 22:39:10 <email address hidden>
 renew until 4.2.2020 12:39:10
3.2.2020 12:42:39 3.2.2020 22:39:10 <email address hidden>
johndoe@computer:~$ ls -la /tmp/krb5cc_1000
-rw------- 1 johndoe johndoe 3125 úno 3 12:42 /tmp/krb5cc_1000

Stefan Priebe (s-priebe) wrote :

Sorry this sucks guys - when is it going to get fixed? Ubuntu 20.04 also stopped working for me since the transition to snap happend - all kerberos and gssapi authentications no longer work

Alexey Tsitsin (cicin) wrote :

This problem still persist and SPNEGO won't work even with new policies:


The policies are loaded successfully but kerboros negotiation won't work

information type: Public → Public Security
Sebastien Bacher (seb128) wrote :

Why do you think it's a security issue?

Alexey Tsitsin (cicin) wrote :

Sorry, I changed the issue's type accidently.

information type: Public Security → Public
Olivier Tilloy (osomon) wrote :

The snap should have the required libraries to support kerberos authentication, but it's likely that confinement is getting in the way. Does kerberos allow verbose logging on the server end, to inspect where authentication is failing?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers