It was even stranger this morning. I reverted my snapshot, installed
the custom Snap, and was able to browse to HTTPS sites successfully.
After I closed the browser, generated a Kerberos TGT, and started the
browser again, all certificates (internal and external) were once again
untrusted. Destroying the Kerberos TGT did not help validate HTTPS
sites.
>I assume you did do the pre-requisite steps, i.e. connecting the interface
The "interface" in this context is the same as the "plug" ('snap connect
firefox:kerberos-tickets'), correct? I wasn't able to get that far as my first
goal was to reproduce authentication failure on a Kerberos-only site, but I've
been unable to consistently validate an HTTPS connection with the
manually-installed snap. Enabling the 'firefox:kerberos-tickets' interface did
not appear to help the HTTPS validation issue.
>and putting the server in trusted-uris.
We use policies in order to configure the Kerberos trusted URIs. Ex:
"policies": {
"Authentication": {
"Delegated": [
"example.com"
],
"Locked": false,
"NTLM": [
"example.com"
],
"SPNEGO": [
"example.com"
]
},
}
Looking in the custom Snap Firefox's 'about:policies' and 'about:config'
shows that these URIs are consistent, though I've also heard that non-
ESR Firefox does not apply the policies file... though what I'm seeing
in the GUI suggests that the policies are being applied.
I don't believe bug #1901586 is the issue. Yes, we install our internal
Root CAs under '/usr/local/share/ca-certificates/', but we also run
'update-ca-certificates' after installing our internal Root CAs.
Furthermore, the issue is trusting *any* certificate, not just our
internal Root CAs.
So there are three potential avenues for errors:
1. I'm not installing/configuring the .snap package properly
2. Something changed in the newer version of Firefox
3. Something changed as a result of using Firefox Nightly instead of Firefox
ESR
I'm not particularly familiar with Snap, so #1 is quite possible. I
could try a run on Ubuntu 25.10 when able.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1849346
Title:
[SRU] kerberos GSSAPI no longer works after deb->snap transition
Status in Mozilla Firefox:
New
Status in snapd:
Fix Released
Status in chromium-browser package in Ubuntu:
Fix Released
Status in firefox package in Ubuntu:
In Progress
Status in snapd package in Ubuntu:
Fix Released
Status in snapd source package in Jammy:
New
Status in snapd source package in Noble:
New
Status in snapd source package in Plucky:
New
Status in snapd source package in Questing:
Fix Released
Bug description:
[SRU] 2.71:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2118396
[ Impact ]
Programs that use Kerberos do not have access to Kerberos' tickets (by
default, /tmp/krb5cc*) if snapped, resulting in denied access to
documents that the user would otherwise be able to access if the
program weren't snapped.
[ Test Plan ]
Requires a server that uses Kerberos authentication and a Ubuntu
client, that for the following tests is presumed to have logged into
the server's realm.
1. Reproduce on snapd deb < 2.71
Install the Firefox snap.
Expect:
- websites that used to work with SPNEGO/GSSAPI/kerberos do not work (access
denied).
- 'snap connect firefox:kerberos-tickets' fails because Snapd < 2.71 does
not yet have the corresponding slot.
2. Prove fix on snapd 2.71
First connect the new plug:
snap connect firefox:kerberos-tickets
Then access a document from said server, it should work.
[ Regression potential ]
Unauthorized snaps (i.e., without kerberos-tickets connection) have
access to the tickets.
Snaps fail to launch due to some bug in the implementation logic
merged in https://github.com/canonical/snapd/pull/15519.
---original---
Workaround
----------
Add
default_ccache_name = FILE:/run/user/%{euid}/krb5cc
to the [libdefaults] section of /etc/krb5.conf so that the Kerberos
credentials are stored in a file path a snapped application can read.
Acknowledgement: For many that can't work for {different reasons}, as
stated in multiple comments below. Nonetheless it is worth a mention.
Original report
---------------
I configure AuthServerWhitelist as documented:
https://www.chromium.org/developers/design-documents/http-
authentication
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1849346/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
